Articles
A real base to build on, or a safe way to change what you inherited.
Most software trouble comes down to one decision on someone’s desk: what to build next, or what to change next — usually in a system nobody fully holds in their head anymore.
These articles are written for the person who has to make that decision. They split by the situation you are actually in.
Building something new
A serious place for your next developer to start.
You have an idea, maybe a prototype, and a decision coming: hire a developer, or build the next piece yourself. The question underneath it is not what to add next — modern tools answer that in an afternoon — but where each piece will live once there are ten of them, before the same rule ends up in three places nobody chose. These articles are about getting that right before the real work starts.
Getting the base right
What the next developer inherits on day one, and where each piece of a new product lives before there are ten of them — getting that right before the real work starts.
AI prototypes are fast. Month twelve is the real problem
My prototype works — so why isn't it a product yet?
Before you hire, decide what they inherit
I'm about to hire a developer — what am I actually handing them?
The module map, photographed alive
Is the foundation real, or just a diagram?
What "operable" means: run support from the admin, not the database
Why does operability cost money up front?
What one workflow proves
Why build one real workflow instead of the whole product?
Own the product, license the foundation
If Smallbox builds it, what do I actually own?
Proof you can check
What the Foundation promises, what proves each promise, and how you can check it yourself.
What you could build
Honest explorations of what becomes buildable when an external API meets the foundation — the capability, the modules it rides, and the hard part named.
A support chatbot that knows when to say 'I don't know'
Can I ship a support chatbot that doesn't invent answers?
The product in an email campaigner is everything except the send
What can you build by joining CRM data to email and a schedule?
The signature is the easy part — the proof is the product
Can you build a trustworthy signing portal on an e-sign API and cloud storage?
A billing dashboard is easy until the money moves off-platform
What's actually hard about building a billing dashboard over Stripe and an accounting tool?
Monitoring is easy. Knowing when to wake someone is the product.
What's the smallest real product for watching devices and paging a human?
Translation is the easy part — review and staleness are the product
Is an AI translation layer a real product on its own?
Selling a ticket is easy — surviving the on-sale is the product
What goes into a ticketing SaaS that joins payments to a meeting link?
A social insights dashboard is built on land you don't own
Can you build a durable analytics product on top of social media APIs?
Between time-tracking and payroll, the integration is the product
What can you build between time-tracking and payroll APIs?
Sending the survey is easy. The reply is the product.
Is an SMS-first survey tool a real product or a Twilio demo?
An AI tutor is the feature you add last, not the product you build first
Where does an AI tutor actually help inside a course product?
A PDF report generator is easy until real data hits the template
How do you turn structured data into branded PDFs at scale?
Reminders feel like a product. They're usually a feature
Is an appointment reminder service a real SaaS, or a feature of something bigger?
In content moderation, the review queue is the product
What does a moderation pipeline on vision and text APIs really cover?
Natural language on a spreadsheet — useful, or quietly dangerous?
Could natural language sit usefully on top of a spreadsheet's data?
A product configurator is the build idea where the backend is the easy half
What does the backend for a 'design-it-yourself' product look like?
Field service: the schedule is a hypothesis the day disproves
Where do GPS, maps, and SMS combine into a field-service tool?
Build one channel deep before you build five channels shallow
Can a small team build a credible email+SMS+social sender?
An AI code reviewer dies of noise, not of being switched off
Can GitHub plus an LLM make a review assistant teams actually keep on?
Build alerts on a data feed without teaching people to ignore them
How do you turn a data feed into alerts people actually keep switched on?
Payment plus a calendar plus a video link is not a booking product
What's the smallest real product for booking, paying, and meeting?
What one capability unlocks
What a single external service gives you, what to own locally, and what to leave with the provider.
Generate text with a model you don't own — and a record you do
What has to stay yours when the model belongs to someone else?
Take payment — and keep the record of what was paid for
What should a payment provider never be the only record of?
Send email — and keep your own record that you did
When an email doesn't arrive, can I tell whether we sent it?
Send SMS: the carrier delivers the bytes, you own the consent
What should stay yours when a carrier sends your SMS?
Store the files anywhere — own the index and the rules
Where should my users' uploaded files actually live?
Sign documents — the audit trail you keep, not the envelope they keep
When I use an e-signature API, what's mine to keep and what's theirs?
Fetching CRM records: sync is easy, source-of-truth is the decision
When you pull records from a CRM, who owns the customer?
OCR returns text and a confidence. The confidence is the feature.
How do you trust the text an OCR API pulls from a document?
Accounting sync: the hard part is the reconciliation boundary
What does your system own when you push records to the accounting ledger?
Importing a spreadsheet means adopting a schema you don't control
What breaks when a customer's spreadsheet becomes your schema?
Maps and geocoding: the cache and the cost ceiling are the product
How do you keep a pay-per-call maps API from scaling your bill with your traffic?
Translate text — the call is stateless, your translations are not
If the translation itself is rented, what's actually mine to keep?
Generate images — own what goes in and what comes out
If the image model is rented, what's actually mine to own?
Search your own content — own the documents the index is built from
Should I own the search index, or rent search as a service?
Inherited systems
Safe change in inherited software systems.
You inherited a backend that has been running long enough that nobody fully holds it in their head anymore, and a decision is on your desk about what to change next. These articles are about reading the system honestly before any code moves.
Most engineering advice you will find online assumes the writer wrote the system being discussed. Inherited systems are different. The original authors are gone, the README is older than half the code, and the parts that look ugly are sometimes the parts the business depends on the most.
The articles in this cluster all share one position: technical ugliness is not the same as risk, and a green test suite is not the same as safety. Both are easy to mistake for evidence. Neither is.
What replaces them, in the System Report, is a small set of named ideas:
- The four properties of safe change — observable, testable, reversible, confirmable. A finding is not actionable until each one is answered.
- Test trust classification — high, medium, low, dangerous. The same test type can be all four depending on what it actually anchors against.
- The Business-Use Map — relevance is read from business use, not from how messy the file looks.
- The five kinds of weird behaviour — known, accidental-but-relied-upon, dead, unknown, unsafe. Each one calls for a different action.
The articles below take one of those ideas at a time and unfold it into the buyer’s decision it is supposed to inform.
Diagnostic before surgery
How to think about an inherited backend before any code is changed.
What tests actually buy you
Where green is real safety, where it is only a green checkmark, and where the gap matters.
Reading the system honestly
Where business rules hide, what kinds of weird behaviour you are looking at, and how to handle each one.
Where business rules hide in old codebases
Why is my system always surprising me?
The five kinds of weird code in a legacy codebase
What is this code doing, and is it allowed to disappear?
How to use production-shaped data safely in a test environment
Can I copy production into staging without leaking it?
Working with AI agents safely
Using AI coding tools on a real codebase without inheriting confidence the tool did not earn.
What you should expect to receive
What a real system report contains before any implementation work is recommended.
If the question on your desk is “what do I do with this system?”
The articles describe the lens. The System Report applies that lens to your system, in writing, with evidence and a recommended next move. The conversation can start with as much or as little context as you are comfortable sharing.