Malachite
Open-source platform for commercial proposals and service planning.
The system I would have built if the two I shipped had been designed as one from the start. Proposals that get revised, priced and audited, then turned into a plan with work fronts, sized resources and requirements — one domain instead of two that have to be reconciled. Written from scratch on my own time, in Django rather than the FastAPI I already knew, and in the open so the reasoning is inspectable.
- Status
- In development
- Period
- 2026 — present
- Context
- Open source · Personal
- Domains
- Commercial · Planning · Accounts · Shared
The problem
Commercial and planning work in industrial services lives in spreadsheets and email threads. Revisions overwrite each other, the number a client was quoted becomes impossible to reconstruct, and the plan behind that number is never connected to it. The hard part is not the UI: it is modelling a proposal that changes over time without losing the history of what was agreed.
Approach
- 01Model the proposal as an entity with immutable revisions, so any past version can be reconstructed exactly.
- 02Freeze pricing into economic snapshots at revision time, decoupling reported figures from later catalogue changes.
- 03Derive planning — work fronts, resource sizing, requirements — from an approved revision, keeping a traceable link between what was sold and what is executed.
- 04Record an audit trail on every state transition, as a first-class part of the domain rather than a logging afterthought.
Architecture
How it is put together.
Django + DRF, modular monolith
One deployable, explicit internal boundaries. Each context owns its models and services; cross-context access goes through a narrow public interface instead of reaching into another app’s tables.
Bounded contexts
Commercial (proposals, revisions, snapshots), Planning (work fronts, sizing, requirements), Accounts (identity and permissions) and Shared (cross-cutting primitives).
Append-only history
Revisions and snapshots are written, never mutated. Auditability falls out of the data model instead of being reconstructed from logs.
Portable persistence
PostgreSQL first, kept compatible with SQL Server — the constraint most enterprise deployments actually impose.
React front end
A typed React client against the DRF API, scoped to the flows that need real interactivity.
Docker + GitHub Actions
Reproducible local environment and CI running the test suite and linters on every push.
Stack
- Backend
- Python
- Django
- Django REST Framework
- Front end
- React
- TypeScript
- Vite
- Data
- PostgreSQL
- SQL Server compatible
- Platform
- Docker
- GitHub Actions
Outcome
- The public reference for how I structure a domain-heavy backend: boundaries, naming, tests, migrations.
- Written from scratch on personal time against a generic problem statement — no employer code, data or client information is involved.
- A deliberate way to learn Django and DDD-style boundaries, coming from FastAPI.
- In development — the repository goes public once there is something worth reading.