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
Automated testing took releases from monthly to weekly
If you cannot debug it, prove it before it ships.
- Python
- Assembly
- Emulator test harness
- Automated release pipeline
Approach
How the work actually goes.
Four stages. The risky part comes first, on purpose.
- 01days, not weeks
Scope
A conversation, then a short written document: what we are building, what it costs, what it will not do, and how we will both know it worked. Nothing starts until you have agreed to it.
- 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
Something working in your hands every week, in an environment you control. You are never waiting on a reveal, and you can change direction without losing what is 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?
Describe it and you will get a straight answer about whether we can help and what it would take.
Start a conversation