Custom enterprise systems

What this is

These are the systems your business runs on that no vendor sells the right version of: the CRM that matches your sales motion, the ERP that fits your production reality, the internal tools that take manual work off your team’s plate. We build them by putting an engineer inside your operation — forward-deployed — instead of taking orders from a distance. The longer argument for why that model works at SMB budgets is in forward-deployed engineering for SMBs.

The problem we usually walk into

A typical engagement starts with a process that runs on a stack of spreadsheets and an off-the-shelf system nobody likes. The off-the-shelf tool forces your process into its data model. The spreadsheets fill the gaps it left. Nobody trusts the numbers, because the same customer or part exists three times with three spellings, and there’s no single record anyone can point to.

The first thing we do is sit with the people doing the work and map what actually happens — the steps, the exceptions, the handoffs that live in someone’s head. That map becomes the schema. We’d rather spend a week getting the data model right than ship a clean-looking app on top of the wrong one.

How we build it

The default stack is a TypeScript app on Next.js with a Postgres database, deployed to Cloudflare Pages. We use Neon for serverless Postgres so the database scales to zero between bursts of use — most internal tools sit idle overnight and on weekends, and you shouldn’t pay for an always-on instance to serve a team of forty. File-heavy systems (scanned contracts, design drawings, exported reports) keep their blobs in Cloudflare R2, which has no egress fees, so pulling a year of documents back out for an audit doesn’t generate a surprise bill.

A few decisions we make on most builds:

• One record per real-world thing. Customers, parts, and orders get a single canonical row with a stable ID. Imports dedupe against it instead of appending another near-duplicate. This is unglamorous and it’s most of what makes the reporting trustworthy later.
• Authorization is checked on the server, per object. Every request that reads or writes a record re-checks, on the server, that the signed-in user is allowed to touch that specific record — not just that they’re logged in, and not by hiding a button in the UI. Missing object-level checks are the top category in the OWASP Top 10 (Broken Access Control), and in a multi-tenant CRM or ERP that’s the difference between a sales rep seeing their accounts and seeing everyone’s.
• Migrations are dry-run first. We run the legacy-to-new migration against a copy, diff the row counts and totals, and reconcile every mismatch before we touch production. Cutover happens in a window, with the old system still readable until you sign off.

A typical engagement

Six weeks is the usual shape for a single-system build; bigger scopes stretch it, but the phases stay the same. This schedule is what “weeks instead of quarters” means in practice.

Week 1: on-site workflow mapping. The sitting-with-your-team week described above: watch the process run, map the steps and exceptions, turn the map into a data model you sign off on. Nothing gets built before this is done, because everything downstream derives from it.

Weeks 2–5: build. We build on the reusable core we carry between engagements — authentication, access control, imports, reporting — and spend the time on what’s specific to your operation. From the first build week you’re looking at working software on a copy of your real data, so you can correct us early: a screen that’s wrong on day ten costs an afternoon; wrong at delivery, it costs a rebuild.

Week 6: migration and cutover. The dry-run migration described above, repeated until the numbers reconcile, then a cutover window with the old system still readable until you sign off. We stay through the first days of live use — that’s when the exceptions nobody remembered turn up.

A worked example

The clearest picture of the finished thing is the custom-furniture manufacturing platform we built: order intake, online parametric design, automatic quoting, saw cutting with offcut nesting, procurement, and sales commission — one closed loop on a single Postgres database. An order is entered once; the quote, the cut list, the purchase requirement, and the commission split all derive from that one model, so a dimension change after the quote updates all of them at once. The write-up covers the tradeoffs — constraining the nesting optimizer, commission as a rule engine rather than a hard-coded rate — because the decisions transfer better than the feature list.

Where we add the most value

• Replacing off-the-shelf systems you’ve outgrown or have to fight every day
• Connecting CRM, ERP, and the tools that don’t talk to each other
• Migrating off fragile legacy systems with zero downtime
• Turning a manual, spreadsheet-run process into software you own

What you get

The code is yours — repository, deployment config, and documentation, handed over so your team can run and extend it without us. Where we made a non-obvious call, there’s a short note in the repo explaining why, so the next engineer doesn’t have to reverse-engineer the reasoning.