Work
Things we actually shipped.
5 projects, all in use. Each had a domain problem sitting underneath the software problem — and getting that part wrong would have shipped a working application that was useless.
A property-tax engine that refuses to file a losing appeal
The bill is not driven by the value you get to appeal.
- Python
- FastAPI
- PostgreSQL + PostGIS
- Cloud Run
- Cloud SQL
The document-chasing layer a leasing platform never had
Chasing a document is a state problem, not an email problem.
- Python
- FastAPI
- PostgreSQL
- Cloud Run
- Cloud SQL
Turning pages that no longer exist into citable evidence
The value is in the coverage, not the best example.
- Python
- Wayback CDX API
- BeautifulSoup
- pandas
Knowing which client is actually ready to file
The bottleneck is not reading the documents, it is knowing what is still missing.
- React
- Python
- PostgreSQL
- Firestore
- Firebase
Building a shippable game in one hour, on 1982 hardware
If you cannot debug it, prove it before it ships.
- 6502 assembly
- ACME
- Python
- VICE
- exomizer
Approach
How the work actually goes.
Four phases. The risky part comes first, on purpose.
- 01days, not weeks
Scope
A conversation, then a written scope: what we are building, what it will cost, what it will not do, and how we will both know it worked. Nothing starts until that document is agreed.
- 02the risky part first
Prove
We build the piece most likely to fail before the pieces certain to succeed. If the accuracy will not get there, or the legacy system will not give up its data, you find out early and cheaply — while changing course is still easy.
- 03visible weekly
Build
Working software in your hands every week, in an environment you control. You are never waiting on a reveal, and you can redirect at any point without losing the work already done.
- 04the actual finish line
Hand over
Code in your repository, infrastructure in your cloud account, runbooks written, and a walkthrough with whoever inherits it. A project is not finished when it runs — it is finished when it runs without us.
Measured, not asserted
If we claim a system is accurate, there is an evaluation set behind the claim that you can run yourself.
Boring where it counts
Novel technology gets used where it earns its risk. Everything else is chosen to be maintainable.
You own everything
Your repository, your cloud account, your data. No proprietary runtime, no hostage infrastructure.
Candid about fit
We turn down work we are not right for. Referring you elsewhere costs us one project and saves you a bad quarter.
Have something with a domain problem underneath it?
Those are the ones worth talking about. Describe it and you will get a straight answer about what it would take.
Start a conversation