Sellable Software Show us what you have

Four systems in use today, and one that never sent.

Five write-ups: three built for clients, two of our own. Four are in use today; the fifth was built and never sent a message, and it is here for that reason rather than in spite of it. The same fleet and the same senior engineer produced all of them. Client systems run in the clients' own accounts, so their commercial figures are theirs to publish and are not here; what a build took and what it changed is ours to describe, and that is the only kind of number below. Two smaller jobs inside other people's systems are left off. Want to speak to a client? Ask; we introduce you if they agree.

KIMA, real estate, Germany Rebuilt

Deal management for German real-estate firms. Arrived vibe-coded on a spreadsheet, rebuilt on a queue.

ArrivedRebuilt The appbuilt with a tool reads and writes A spreadsheetdoing the job of a database Someone has to remember to update the row. The appmoves on the record Every change, recordedthe moment it happens. A queue, not a memory. A real database Nobody has to remember anything.
As it arrived, and as it runs now. A queue, not a memory.
  1. What arrivedA tool for tracking property deals, built with an AI tool. It ran on a spreadsheet doing the job of a database.
  2. What we rebuiltEvery change to a deal is recorded the moment it happens, and the app moves on that record. Nobody has to remember to update a row.
  3. What happened nextThey have been adding features themselves, with AI, since the rebuild, and nothing has broken so far. That is what this system has done, not what it is promised to keep doing.

“They can hand the codebase to Claude now and add features without breaking anything.”

Client, KIMA, quoted with permission. The description above is ours, not theirs.

Ush, executive scheduling, UK Built from a spec

Meeting scheduling for executive assistants: ranked slots with reasons, on weights you tune. Built 2025 to 2026. They arrived with a spec and screen designs, not an AI-built app, and neither was built: the spec turned out to be wrong, and the product that shipped replaced it. Beta in one month, useful at four, and ten months later they were still buying weeks, forty in all, one at a time.

Scheduling is a constrained optimisation, not a workflow. Finding that shape was the architecture.
  1. The problemAn executive assistant picks a slot on dozens of implicit factors: habits, travel time, who outranks whom, what the other side can move. That logic lives in a head. Put a second assistant on the same principal and the heuristics stop agreeing; ask an engineer to write them down and they turn into prose nobody can run.
  2. The shapeScheduling is a constrained optimisation, not a workflow. Once the assistant's judgement is weights, hard constraints filter and soft constraints rank, and every suggestion is reproducible instead of a black box. Finding that shape was the architecture; there was no process to automate and no system to integrate.
  3. What was builtA web app and a separate background worker sharing one PostgreSQL store for sessions, the job queue and storage, with nothing on top of it. Docker Compose on one server behind nginx. Travel time between back-to-back meetings rejects the physically impossible slots. A language model writes the explanation and never picks the slot. Every query is scoped to one user, so several principals share a deployment and never share a calendar.
  4. What was refusedThere is no send scope. Mailbox access is read and compose only: Ush drafts and a human sends. That is a product decision, not an unfinished feature.
  5. What came of itScheduling round-trips down to roughly one interaction, which is the only hard number it has. The spec was wrong, and not building it was the value delivered.

A research platform, science, Israel Built

Papers and internal documents as a knowledge graph, for fifteen PhDs and no engineering function. Papers arrive as PDFs and their reference lists; a model is called stage by stage to extract who claimed what on which page. Search that graph in plain language and the answer is the quoted passage and a citation to the page it came from: extraction a reader can check, not a paraphrase they have to trust. Client system; its figures are the client's to publish.

Extraction a reader can check, not a paraphrase they have to trust.

SignalsAPI, recruitment Ours

Sources scraped for buying signals, at a scale that runs without an ops rota. Sources go to a bank of fetch workers, then normalise and dedupe, then classify into a store the API reads from. Thirty-odd services is that line, run at that width, with no DevOps engineer. It is on this page as evidence the method builds real things, not as a client outcome. These four figures came off it, and they are the only ones we are free to publish.

1MPages a day
457Sources scraped
30+Services live
0DevOps engineers
Thirty-odd services is that line, with no DevOps engineer.

Virtual BDR, sales Ours

LinkedIn and email outreach under one orchestrator: eight programs that run one errand, joined by two thin wires. Only one of them composes a message, and it hands it to an outside sender behind one seam. Every row of purchased data is gated before each charge. Nothing has been sent yet: the send credential was never placed, which reads either as safety machinery working as built or as gates set so tight nothing got through. We don't claim to know which, and no figures are published.

Safety machinery working as built, or gates set so tight nothing got through. We don't claim to know which.

Three things we talked a client out of buying

The thing you want to sell is probably the next one. That is the claim worth testing: that the method transfers, and not just that these worked.

Show us what you have Book twenty minutes

If you're the engineer this got forwarded to, start at how it works instead.