ERPNext Custom Development, DevOps & Production: The Bangladesh Case Study Playbook

🔁 Custom Development Lifecycle

Parts 2 and 3 of this series walked through the hospital's Clinical Management and Laboratory modules and the real estate firm's Property and Construction modules from the business side — what each screen means and why it exists. This part walks through the same four custom modules from the developer side: how a requirement actually becomes a DocType, a controller, a UI, an API, and eventually a deployed, monitored production system. This is the same custom-development lifecycle that Building a Custom Frappe App in the 9-part course covers generically — this part applies it concretely to the two real projects instead of a single teaching example.

Every DocType covered in this part — Patient, Lab Request, Property Unit, Property Booking, and the ones behind them from Parts 2 and 3 — passed through this exact chain. Skipping a step (most commonly permission design or testing) is where custom Frappe apps tend to accumulate the kind of technical debt that only surfaces once real users hit the system in production.

📦 Custom App Structure for Both Projects

Both custom domains — hospital and real estate — can share one physical app layout, split into two module folders. The base directory pattern is the same one covered in the 9-part course's custom app structure section; the only difference here is that this app carries two unrelated business domains side by side instead of one:

custom_app/
├── hooks.py
├── modules.txt
├── patches.txt
├── public/
├── templates/
├── api/
├── config/
└── custom_app/
    ├── hospital/
    │   ├── doctype/
    │   ├── report/
    │   ├── page/
    │   └── workspace/
    └── property/
        ├── doctype/
        ├── report/
        ├── page/
        └── workspace/

One app with two module folders and two separate apps are both legitimate choices, and the right one is a deployment decision more than a technical one:

🧱 Four Worked DocType Designs

Parts 2 and 3 already explained what these DocTypes mean to the business — see Clinical Management and Laboratory for the hospital, and Property/Sales and Construction Management for real estate. This section covers the same four DocTypes from the developer view: how they'd typically be shaped as DocType definitions, illustratively — exact field names and behavior always depend on the actual implementation and version.

Patient (Hospital)

Lab Request (Hospital)

Property Unit (Real Estate)

Property Booking (Real Estate)

🐍 Python Business Logic

Doc-event hooks are where server-side rules actually live, because — unlike client scripts — they cannot be bypassed by a browser tab or a direct API call:

The following is illustrative syntax only — a shape a validate() method for a Lab-Request-style controller might take, not exact code from a real deployment:

# Illustrative syntax — not guaranteed exact for any specific version
class LabRequest(Document):
    def validate(self):
        # validate patient
        # validate requested tests
        # validate status

Not every piece of logic belongs in the same place — picking the right layer matters as much as writing correct logic:

🖱️ JavaScript / Client-Side

Client scripts shape what the user experiences in the moment: which fields appear, what a Link field's query is filtered to, what gets fetched from a related document, and what inline validation warns about before a save is even attempted. Typical client-side responsibilities include form events (refresh, onload, field-level triggers), dynamic field visibility, Link field queries scoped to relevant records, pulling and displaying data from a linked document, and lightweight UX-level validation.

The following is illustrative syntax only:

// Illustrative syntax — not guaranteed exact for any specific version
frappe.ui.form.on("Lab Request", {
    refresh(frm) {
        // UI behavior
    }
});

🔐 Security Architecture

For the full depth on roles and permissions, see Users, Roles & Permissions and the hardening checklist in Security Hardening. Every layer below matters — skipping any one of them is where real incidents tend to start:

🧵 Redis in This Architecture

Redis is not optional infrastructure sitting off to the side — several core pieces of the stack depend on it directly:

Redis backs the background job queue, response/data caching, and the real-time pub/sub channel that Socket.IO uses. If Redis becomes unavailable, the general expectation — not a guarantee for any specific version or deployment — is that background jobs (the hospital's nightly reminder emails, a bulk installment reminder job for the real estate firm) stall or stop being picked up, and real-time notifications (like a lab-result approval alert) stop delivering. Whether core document create/read/update/delete through the web process keeps working during a Redis outage depends on how much of that path is cached versus computed live, and should be verified against the actual deployment rather than assumed.

📡 Real-Time / WebSocket

Two illustrative scenarios from the two custom apps:

• Hospital: a Lab Technician approves a Lab Result → a realtime event fires → the requesting doctor's dashboard shows a live notification, without a page refresh.
• Real estate: a Sales Manager approves a Property Booking → a realtime event fires → the sales dashboard updates unit availability for every sales executive currently viewing it.

🗄️ Database Architecture for Production

MariaDB is the primary, long-supported database engine for ERPNext and the Frappe Framework, and it's the safe default assumption for any production deployment in this series. PostgreSQL support has existed in parts of the Frappe ecosystem at various points, but its availability, maturity, and exact capabilities are version and deployment dependent — verify PostgreSQL support and its exact capabilities for the specific ERPNext/Frappe release before choosing it, and do not assume feature parity with MariaDB. This series does not instruct switching database engines and treats MariaDB as the baseline throughout.

🌐 Nginx in Production

🏭 Full Production Deployment Architecture

Every box in this diagram appeared individually earlier in the series — the Beginner course's production diagram covers the same shape at a general level; this version reflects the full path both the hospital and real estate deployments run in practice.

🔄 CI/CD Pipeline

• Git as the single source of truth for both custom apps' code
• Feature branches per requirement, never committing straight to the production branch
• Pull requests as the review gate before merge
• Version tags marking every release that reaches production
• Release notes summarizing what changed, for both the technical team and the business stakeholders
• Database migrations tested in staging before they ever run against production data
• bench commands (build, migrate, restart) scripted rather than run ad hoc by hand
• A documented rollback strategy for every release, decided before deployment, not improvised after

🏷️ Release & Versioning

A breaking change (removing a field the API relies on, changing a DocType's meaning) bumps the major version; a new, backward-compatible capability (a new report, a new optional field) bumps the minor version; a fix with no behavior change bumps the patch version. Treating these three categories differently is what lets other systems (the hospital's mobile app, the property website) know whether upgrading is safe without reading every commit.

🗃️ Database Migration

• bench migrate as the standard mechanism for applying pending schema/data changes
• Patches for one-off data transformations that a plain schema change can't express
• Schema changes (new fields, changed field types) driven through the DocType definition, not hand-written SQL
• Fixtures for exporting/reapplying configuration (custom fields, roles, workflows) across environments
• Data migration scripts tested against a copy of production-shaped data, not just an empty dev site
• Rollback planning decided before running a migration in production, not after something breaks

See Building a Custom Frappe App for how patches and fixtures are structured, and Backup & Recovery for why a backup always precedes a production migration.

💾 Backup Architecture

• Full database backup on a regular, automated schedule
• File backup covering both private files (lab results, contracts) and public files
• Encryption at rest for backup storage, especially given the clinical and financial data involved
• Offsite backup — never stored only on the same server it protects against losing
• A defined retention policy across daily/weekly/monthly tiers
• Restore testing on a real cadence, not a one-time exercise
• A documented disaster recovery plan (see Disaster Recovery)
• An explicit RPO (Recovery Point Objective) — how much data loss is acceptable
• An explicit RTO (Recovery Time Objective) — how long recovery is allowed to take

📈 Monitoring

📊 Reporting Architecture

🔗 API Integration for Both Projects

• Authentication via API key/secret or OAuth, never anonymous write access
• GET for reads, POST for creates, PUT for updates, DELETE for removals — standard REST semantics
• Webhooks for outbound event notification (e.g. notifying the property website when a unit's status changes)
• Explicit error handling and meaningful HTTP status codes on every endpoint
• Rate limiting to protect the server from a runaway or misbehaving integration
• Logging every external API call for auditability
• Security scoped per integration — see REST API Deep Dive for the full mechanics

🌍 External Integration

Illustrative examples per project, not a confirmed integration list for any real deployment:

• Hospital: SMS gateway, email, payment gateway, the hospital's public website, a mobile app, laboratory instruments (where technically supported by the specific hardware/interface), and accounting/reporting systems
• Real estate: the public marketing website, lead capture forms, payment gateway, SMS, email, maps, a customer self-service portal, and document/e-signature systems

🧩 Custom Module API Examples

POST /api/method/hospital.api.create_lab_request
GET  /api/method/hospital.api.get_patient
GET  /api/method/hospital.api.get_lab_result

GET  /api/method/property.api.available_units
POST /api/method/property.api.book_unit
GET  /api/method/property.api.installments

These are illustrative example endpoint names only; actual endpoint design, naming, and security depend on the real implementation and must be reviewed against the target version's whitelisted-method conventions.

🧪 Testing Strategy

✅ Deployment Checklist

🆘 Disaster Recovery

• RPO (Recovery Point Objective) — how much data the business can tolerate losing
• RTO (Recovery Time Objective) — how long the business can tolerate being down
• Backup retention long enough to cover the realistic detection window for a problem
• Restore testing done on a schedule, so the first real restore isn't the first attempted one

🏥 Business Continuity

Hospital: if ERPNext becomes unavailable during an emergency admission, the fallback is a paper-based manual process — a physical admission form, a manually logged Lab Request slip — that keeps patient care moving without waiting on the system. Once ERPNext is restored, that paper trail is entered back in as a reconciliation step, cross-checked against what actually happened during the outage before anything is billed or closed out.

Real estate: if ERPNext becomes unavailable while a buyer is ready to book a unit, the fallback is a temporary manual capture of the transaction (a paper or offline booking form) rather than losing the sale. Once the system is back, that capture is reconciled into a proper Property Booking record — with an explicit check against double-booking, since a unit could otherwise be manually promised to two buyers during the same outage window.

⚡ Performance & Scalability

• Database indexes on frequently filtered/joined fields
• Query optimization before reaching for more hardware
• Redis caching for expensive, frequently repeated reads
• Background jobs for anything that doesn't need to block the user's request
• Queue workers scaled to match actual job volume
• Pagination on every list/report that can return large result sets
• Reports designed with large datasets in mind from the start, not retrofitted after they get slow
• File storage that scales independently of the database
• API responses optimized to return only what the caller needs

The hospital's Lab Result history can realistically grow into millions of rows over years of operation, and the real estate firm's installment records can reach thousands of customers with recurring schedules — both are the kind of growth that makes indexing and query design matter more than raw server size.

🏢 Multi-Company & Multi-Branch

Branch examples: the hospital operating Dhaka Main Branch, Chittagong Branch, and Sylhet Branch; the real estate firm operating a Dhaka Office, a Chattogram Office, and individual Project Site Offices. Branch architecture isn't cosmetic — it affects how Warehouses, Cost Centers, and User/permission scoping (see User Types) are structured across the whole deployment.

⚖️ Hospital vs Real Estate: The Complete Comparison

The shape is identical in both columns — only the vocabulary changes. That's the core lesson of the whole series: ERPNext's core modules (Accounting, Stock, HR, Projects) don't change between industries; only the custom module vocabulary layered on top of them does.

🧭 Final Architecture: One Diagram for the Whole Series

Everything in this series — the methodology in Part 1, the two custom apps in Parts 2 and 3, and every mechanism in this part — is one instance of this one diagram.

🗺️ Developer Roadmap

🧩 The Decision Framework, Applied

Every custom DocType and workflow built across both projects in this series — Patient, Lab Request, Property Unit, Property Booking, and everything alongside them — was arrived at by walking Part 1's Configure vs Customize vs Custom Module vs Integration decision framework: does an existing ERPNext feature already cover this? Configure it. Can a field or workflow addition cover it? Customize it. Does it need a genuinely new business object ERPNext has no concept of? Build a custom module. Does it need to talk to something outside ERPNext entirely? Build an integration. Two real, fully worked projects later, the framework held up in every case — nothing in this series needed to bypass it or modify ERPNext core.

🎓 Final Project Assignment

Project A: Hospital Management ERP

Minimum requirements: Patient, Doctor, Appointment, Admission, Lab, Pharmacy, Billing, Accounting, Inventory, HR, Payroll, Reports.

Custom Apps: Hospital Clinical Management, Laboratory Management.

Project B: Real Estate & Construction ERP

Minimum requirements: Lead, Customer, Project, Building, Unit, Booking, Installment, Construction, BOQ, Procurement, Stock, Accounting, HR, Payroll, Reports.

Custom Apps: Property Management, Construction Management.

Both projects follow the same deliverable chain, start to finish:

🏁 Series Complete

This closes the 4-part ERPNext Bangladesh Implementation Case Study: Part 1 — Implementation Methodology, Part 2 — Hospital Management, Part 3 — Real Estate & Construction, and this part, Part 4 — Custom Development, DevOps & Production.

Taken together with the existing 9-part ERPNext Beginner to Intermediate course and the two framework-agnostic accounting-theory posts — Invoice vs Payment: The Complete ERP Accounting Architecture and the Accounting to ERP curriculum — this site now carries one coherent body of ERPNext knowledge: the general architecture and course material, the accounting theory underneath it, and this case study series showing that architecture and theory applied to two real, fully worked Bangladesh businesses. Any one piece can be read on its own; read together, they form a complete path from "what is ERPNext" to "how do you actually build and run a production ERPNext deployment for a real business."