The spreadsheet is the system
It has grown formulas nobody dares touch, three tabs that must be updated together, and a copy on somebody's desktop that is now the real one. Nothing validates anything, and there is no record of who changed what.
Custom software
The system your business actually runs on
Most small businesses run on a spreadsheet somebody inherited, a messaging group, and a person who remembers how it all fits together. That works until it does not — until two people edit the same row, until the person is on holiday, until nobody can answer how much is outstanding without an afternoon of adding up.
Sound familiar
Four ways this usually shows up
None of these is a failure of organisation. They are what happens when a business outgrows the tools it started with.
The same data lives in five places
Orders in a chat, stock in a spreadsheet, invoices in a folder, customers in someone's phone. Every question that spans two of them is a manual reconciliation, and the answers quietly disagree.
Off-the-shelf almost fits
It does eighty per cent, charges per seat for all of it, and the missing twenty per cent is the part specific to your business — which is to say the part that matters.
Nothing talks to anything
The accounting package, the online store and the till each have an export button, and joining them up is somebody's Monday morning.
Approach
What we build instead
One database that is the authoritative record, an interface that fits the people using it, and integrations that move data automatically rather than by export and re-import. Small enough to finish, structured well enough to extend.
One system of record
A real relational database — normally PostgreSQL — with constraints that make invalid data impossible rather than merely discouraged. Two people cannot disagree about a total, because there is only one total.
An interface that suits the user
A Telegram mini app for staff on their feet, a web interface for anyone at a desk, a bot for quick queries. Often all three against the same data, because the person taking an order and the person chasing payment want very different screens.
Structured capture, not free text
Data validated at the point of entry, so the reporting at the other end is trustworthy. Where people prefer to write in plain language, the message is parsed against your real catalogue and confirmed before anything is filed.
Integration as a first-class part
REST APIs, webhooks, scheduled syncs, CSV import and export for anything with no API at all. If a system can be reached programmatically, it can be joined up; if it cannot, the import path is at least made boring and repeatable.
Reporting that comes to you
Daily and weekly summaries pushed to Telegram or email on a schedule. A dashboard nobody opens is not reporting; a message at 23:30 with the day's numbers is.
An audit trail
Who changed what, when, and what the value was before. Cheap to build in from the start and effectively impossible to add retrospectively once it matters.
Built and running
Systems we have actually shipped
Every one of these is in production, not a proposal. Most of them run our own businesses, which is the strongest thing we can say about them.
Order intake to paid invoice
A customer messages an order in plain language. It is parsed against the live catalogue, matched to a customer record, priced and filed. A real PDF invoice is generated in code and delivered to their chat, and a 09:00 digest chases anything still open.
Natural-language capturePostgreSQLPDF generationScheduled digest
Point of sale with staff roles
A till running as a Telegram mini app against an action-routed API: catalogue, open tabs, checkout, live takings. Permissions resolve from the staff member's own account and are enforced at the API, and a sales summary is pushed nightly.
Telegram mini appRole-based accessNightly reporting
The whole operation in one app
Inventory ledger, brewing, assets, maintenance and finance as modules of a single mini app. Every module is a set of Postgres functions, every mutation checks the caller's role and writes an audit row, and the app shell itself is versioned in the database — rollback is reposting the previous build.
Role-gated modulesAudit trailVersioned deploys
Receipts to reconciled books
Photograph a receipt and it is filed. Every three days the folder is reconciled against the ledger: gaps appended, duplicates and anomalies flagged, and a summary posted to the accounting group — bookkeeping that heals itself instead of drifting.
Receipt captureScheduled reconciliationAnomaly flags
Two clubs, one pattern
A darts team and a dominoes club run on the same platform pattern: schema, business logic as Postgres functions, a versioned app shell and one audited send gate. The second system took a day, because the first was built as a pattern rather than a one-off.
Platform patternPostgres functionsSecond deploy in a day
Environmental data as a system
Sensor readings logged continuously with configurable alarm thresholds, escalating alerts until acknowledged, and history retained for trend analysis and compliance records.
Time-series dataAlarm thresholdsCompliance history
What it is made of
Boring technology, on purpose
Nothing here is fashionable. A relational database, a small amount of orchestration and interfaces people already know how to open. The point is that someone else can still maintain it in three years.
- Your infrastructure, your database, your credentials
- No per-seat licence and nothing that stops working if we do
- Documented at handover, schema included
| Database | PostgreSQL, or MySQL where it is already in place |
|---|---|
| Integration & orchestration | n8n, with code where a workflow would be the wrong tool |
| Interfaces | Telegram mini apps, web apps, bots, PDF documents |
| Integration surfaces | REST, webhooks, scheduled sync, CSV in and out |
| AI, where it earns its place | Parsing messy input, transcription, drafting — never unreviewed decisions |
| Hosting | Your server or ours. Containerised, documented, portable |
| Handover | Schema documentation, credentials in your name, a written runbook |
Straight answer
When we will tell you not to
Custom software is the right answer less often than people selling it suggest. These are the cases where we will say so.
- If an off-the-shelf product genuinely fits, buy it. Custom software is a long-term commitment to maintenance, and a licence that fits is cheaper than one you have to keep alive.
- If the process is not settled yet, building software will just freeze the confusion. Sort the process out on paper first, then automate what survives.
- If only one person does the task once a month, the automation will cost more than it saves. That is a fine answer and we would rather say it early.
- If the data is a mess, cleaning it is the project. Anyone who quotes a migration without looking at the data has not looked at the data.
Process
Four steps, and you can stop after any of them
- 01
Conversation
A call or a Telegram thread about what actually goes wrong in your week. No discovery invoice.
- 02
Fixed scope
A written scope with a price against it. If the honest answer is that automation is not worth it here, you get that instead.
- 03
Build
Built in the open with something to look at early. You see it working before it is finished.
- 04
Handover
Documentation, credentials in your name, and a walkthrough. You own it whether or not we keep working together.
Tell us what keeps going wrong
A conversation costs nothing and often ends with us saying automation is not worth it for a given job. That is a useful answer too.