# Build brief — a focused alternative to ERPNext

> **Verdict:** Not faithfully · **Buildability:** 13/100 · **Category:** Finance Accounting
> **Source:** https://www.canitbevibecoded.com/erpnext
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from ERPNext. Verify current pricing and capabilities before acting.

## Context

**ERPNext** — Open source ERP covering accounting, inventory, manufacturing, HR, CRM and projects in one system. It currently costs $5/mo.

ERPNext is not one app, it is roughly a dozen interlocking ones: a double entry ledger, stock with valuation methods, bills of material, purchase and sales cycles, payroll, and reports that accountants and auditors expect to look a certain way. An agent can absolutely one-shot the shape of any single module, and the result will feel great until you post a credit note, revalue stock, or try to close a fiscal year. The deeper joke is that the software is already free: the code is open source and self-hostable, so rebuilding it from scratch is the one move that makes no sense. If you pay, you are paying Frappe for hosting, upgrades and someone to call. The honest DIY option is either running ERPNext yourself or building a deliberately tiny ledger for one small business and accepting it will never be an ERP.

This brief describes a focused, single-operator replacement for the part of ERPNext that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

A self-hosted mini ledger: items, contacts, sales and purchase invoices, payments, stock on hand, and correct double entry behind it all with P&L and balance sheet.

- Model a narrow bookkeeping workflow with explicit review and export steps.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- Python 3.12 and a machine that stays on.
- Willingness to keep your own backups.
- An accountant who will look at the numbers before you trust them.

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

Build a small self-hosted bookkeeping and stock app for a one-person business. This is NOT an ERP replacement and should not pretend to be one.

Stack, no substitutions:
- Python 3.12, Django 5, SQLite, Django admin as the primary UI
- Plain Django templates for the few custom pages, no JS framework
- Run with `python manage.py runserver`, no Docker, no cloud, no accounts, no telemetry
- Secrets (SECRET_KEY only) read from .env via python-dotenv, ship .env.example

Data model:
- Account (code, name, type: asset/liability/equity/income/expense)
- JournalEntry (date, memo) with JournalLine (account, debit, credit); enforce that each entry balances to zero at save time and refuse to save if it does not
- Party (customer or supplier, single model with a flag)
- Item (sku, name, unit, sale price, purchase price, current qty)
- SalesInvoice and PurchaseInvoice, each with lines (item, qty, unit price); posting an invoice generates the matching JournalEntry and adjusts Item qty
- Payment (party, date, amount, direction) that also posts a JournalEntry

Behaviour:
- Seed a minimal chart of accounts on first migrate: Cash, Bank, Accounts Receivable, Accounts Payable, Sales, Purchases, Inventory, Owner Equity
- Invoices are draft or posted; posted invoices are immutable, corrections happen via a credit note that posts a reversing entry
- Inventory valuation is simple average cost, and say so plainly in the UI

Reports as read-only pages:
- Trial balance for a date range
- Profit and loss for a date range
- Balance sheet as of a date
- Stock on hand with average cost value
- Each report has a CSV download

Explicitly out of scope, do not build: manufacturing, payroll, multi-currency, tax engines, multi-user permissions, approval workflows, email sending.

Deliver README.md with setup in under five commands, a seed script that loads a few months of fake invoices and payments, and pytest tests covering: unbalanced entries are rejected, posting an invoice moves stock and hits the ledger, and the balance sheet actually balances.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- Manufacturing: bills of material, work orders, capacity planning, none of it.
- Payroll, leave, expense claims and the statutory reports that go with them.
- Tax templates, multi-currency, and country specific compliance packs that took years to accumulate.
- Upgrades, migrations and a support contract when the ledger disagrees with the bank.
- The ecosystem: apps, integrations, consultants who already know the data model.

## What you still own after launch

- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.
- Maintain every third-party integration as APIs and OAuth rules change.

## Risk

**High consequence.** Use this as a prototype or personal aid. Keep a qualified human and an established provider in the loop for consequential decisions.

Editorial confidence in this assessment: medium. No reviewed project implementation is linked yet.

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/erpnext