Build
We build the software.
The systems a company runs on: ERP and logistics platforms, CRM, point of sale, HR and payroll, internal portals and customer-facing products. Built from the schema up, priced fixed, shipped in weeks rather than quarters.
- Projects
- 20
- Figures published
- 4
- Free first step
- Build Map
- Fixed price from
- $2K
4 written up on the work page
listed on the work page
built from the system you are outgrowing, or the process nobody has a system for
Operational Platform Build
Is this you
The week this fixes.
Sentences we hear from the people who end up sending this practice a bottleneck, and what each one is costing while it stays true.
“Only one person understands that spreadsheet.”
One file the whole operation depends on, and one person who can touch it.
“Budget approved, roadmap committed, engineers not hired yet.”
A quarter spent on specifications that describe the product instead of running it.
“We are working around the software we pay for.”
A platform that fits two thirds of the process, and people covering the third that it does not.
What a project covers
Scoped to the smallest useful system, judged against a number.
- Operational platforms: ERP, CRM, POS, HR and payroll, inventory and purchasing, built to the workflow that exists
- Internal tools and portals, with the roles, permissions and history the current process is faking
- Prototypes in weeks: a version you can click, show, and test with real users
- Production websites with structured content, so updates do not need a developer
What that has looked like
- An operating system for the business: orders, stock, dispatch and invoicing as one system rather than four
- A CRM or portal shaped around how this company actually sells, not around a template
- A working product version in weeks, not a specification document
The measures we agree before building
One of these is picked with you at the scoping step, and reported against.
- Time to publish a change without a developer
- Hours lost to re-keying between systems that should share a record
- Time from idea to a version users can actually try
No charge, no call
Start with the free one.
Each is a document or a sample, written by the person who would do the work. Send one input, get something back you can act on or ignore.
Free
Build Map
What to build or replace first, what to leave alone, and in what order.
You send: The system you are outgrowing, or the process nobody has a system for. A few sentences, or a screenshot of the spreadsheet.
You get back:
- The part of the process that should become software first, and why that part
- What should stay in the tools you already pay for
- The order the rest goes in, so nothing gets rebuilt twice
Every free first step across the five practices is listed together, if the problem sits between two of them.
Entry points
The ways in, each priced before work starts.
Start with one. None of them requires the next one, and each is small enough to judge on its own.
Operational Platform Build
The workflow a department runs on, built as real software with the roles, records and history it needs.
$2K–$6K · Fixed price · 2 to 4 weeks
Two-Week Prototype
A working version in two weeks, not a specification document. Real data, clickable, and the repository is yours.
$2.5K–$5K · Fixed price · 2 weeks
Site Build and Rescue
A production site with structured content, or the rescue of one that nobody can update without a developer. We run our own store, so this is not theory.
$1.5K–$5K · Fixed price · 1 to 5 weeks
Every price, fixed or by the hour, is agreed before work starts and built the same way: the hours, the tools, and a share of company cost. See how a price is built
The free first step
What the first move looks like.
Examples of what we sent back after a bottleneck came in.
A phased build for a remote-desktop platform, after a working proof of conceptWhat happened: Unsigned. The proof of concept it followed is in the capability catalogue.
An IT services firm had a working proof of concept and needed the path from it to a product its own team would eventually own.
What it covered
- Three phases, each with a handover milestone, and the point at which ownership transferred
- An hour-based estimate per phase, revised once against the client's budget
- Later, a separate scope to move a monitoring tool built on a no-code platform onto a cloud host, with a database migration and a delivery pipeline
- The first move
- Phase one on the relay and the agent, with ownership transfer written into the plan.
A quote packet and a consolidated technical approach for a digital publication readerWhat happened: Proposal reviewed; no award. The discovery deliverable is on the work page.
A publishing startup had a broad, generated statement of work and needed an architecture it could actually execute and price.
What it covered
- A consolidated technical approach: the publisher CMS scope, the system architecture, and the reader
- Team composition, QA and security strategy, acceptance criteria, and a risk register
- A quote packet with the delivery plan
- The first move
- Discovery output first, then a build against it.
The work
What this looks like shipped.
A self-hosted email verification engine built for explainable results
34 reason codes · 25 output columns
An internal product: a bulk verification CLI with DNS and multi-stage SMTP checks that explains each classification instead of emitting a black-box score, deployed on its own verification node and run on real lead lists.
Read the case study
A café operations system: orders, inventory, shifts, loyalty
20-table schema
An internal product built in March 2026: point of sale, the barista queue, an inventory ledger, recipes, loyalty, shifts, and void reversals across a 20-table schema, designed against a 22-entity domain model.
Discovery and architecture for a secure digital publication reader
A completed discovery, scoping, and architecture deliverable for a secure HTML5/PWA manga and magazine reader: user journeys, NFT and fiat entitlements, encrypted delivery with watermarking, publisher CMS and analytics, and a delivery plan, plus deployment troubleshooting on the client's existing product after its move from AWS to GCP.
Read the case study
93 Brew: A café website the owner can update without a developer
A customer website for a café: prices and items are changed in one place and update across the site, each drink has its own page, and the site is set up to be found in local search. We hold a stake in the café.
Read the case study
7 more software projects
What else we have built in this area, and what changed as a result.
Engagements in this catalogue, described without numbers and, in most cases, without the client: they were built under confidentiality or under another firm's brand. For numbers with sources behind them, see the work page.
A quoting tool that replaced the estimator's spreadsheet
Every quote went through one person and one workbook. Pricing logic lived in formulas nobody else could read, and a quote took a day because it had to wait for them.
What we built
- A quoting application holding the pricing rules as data rather than formulas
- Versioned quotes, so a revision is a new record and the old one still exists
- Role-based access, so sales could quote without being able to edit the pricing model
- PDF output matching what the client had always sent, so nothing had to be re-explained to customers
What changed
Quoting stopped depending on one person being available, and a wrong quote became traceable to the rule that produced it.
A client portal that ended the status-update email
A services firm was answering the same question all week (where is my job up to?) by hand, in email, per client.
What we built
- A customer-facing portal showing job state, documents, and history
- Authentication and per-account scoping, so a client sees only their own records
- Automated notification on state change, replacing the manual update
- An internal view so staff could see the same picture the client sees
What changed
Status questions stopped arriving as email, and the team stopped reconstructing answers from memory.
Field data capture that works without signal
Crews recorded jobs on paper because the site had no reliable connection, then someone retyped the paper on Monday.
What we built
- A mobile-first capture app that stores locally and syncs when a connection returns
- Conflict handling for records edited in two places before syncing
- Photo capture attached to the job record rather than a separate camera roll
- An office view where the day's captures land already structured
What changed
The Monday retyping job disappeared, and job records stopped depending on legible handwriting.
Taking over a codebase whose author had left
A business depended on an application nobody currently employed had ever worked on. Nothing was documented and every change was frightening.
What we built
- A read-through and written architecture map of what was actually there
- A test harness around the parts that mattered, before changing any of them
- Dependency and runtime updates, applied in reviewable steps rather than one jump
- A written handover so the next person does not start where we did
What changed
Changes became something the team could make deliberately instead of avoiding.
An employee-management system for a large venue operator
Staff records, scheduling and approvals lived across spreadsheets and email for an operation far too large for either.
What we built
- A central employee record with the approval chain built in
- Scheduling and attendance against that record rather than beside it
- Role-based access, so managers saw their own people and not the whole organisation
- Reporting for the questions administration actually got asked
What changed
Staff administration moved onto one system, and answering a question about a person stopped meaning opening four files.
A remote-desktop relay proof of concept, and the plan to take it to product
An IT services firm needed a remote PC management component that went beyond the open-source proof of concept it had, and a path from proof to product.
What we built
- A React front end and a Windows agent driving remote-desktop sessions through PowerShell, with the relay approaches researched side by side
- A phased build plan with handover and ownership milestones
- A deployment pipeline design to move a monitoring tool built on a no-code platform onto a cloud host, with a database migration and continuous delivery
What changed
The client called the interface clean, funded the continuation, and had a phased plan it could sign against.
Standing up the machinery behind a signed partnership
A partnership was signed before any of the machinery behind it existed: no cloud project, no billing, no shared workspace, and a model integration still to prove out.
What we built
- Cloud project, billing, and a shared workspace stood up between the two sides, so the partnership started work rather than started procurement
- An integration sprint against a hosted large-language-model API
- A joint demonstration prepared with the platform vendor and a third party
- A clean wind-down when the arrangement ended, billing account included
What changed
The partnership had somewhere to work and something to bill against, and closing it down later left nothing running that nobody owned.
Elsewhere on the site
Read next
- PrototypesLabsWorking prototypes on sample data, including the kind of surface this practice builds. Nothing there is a client system.
- The workThe workCase pages, the systems that could not be named, and every figure with its source.
- The workThe evidence registerEvery record behind the work page, what kind of evidence each is, and what is withheld.
Where to next
The free first step: a Build Map.
Send the system you are outgrowing, or the process nobody has a system for. A few sentences is enough.