Custom Software & Data Products
Software built to be handed over.
Most custom software at this size is not a moonshot — it is the tool that fills the gap between two products you already own, or the data product you want in front of your own customers.
not in scope · connecting systems you already run · Automation & Integration
What this silo does not cover, stated in full rather than left to the rail: connecting two systems you already run is Automation & Integration. This silo is for the system that does not exist yet.
company delivery history · founder-asserted ·
We build on Python and .NET as the core, with C#, Java and T-SQL where the estate calls for them, FastAPI services, and React/Next.js or Streamlit front ends over those APIs. Docker and CI/CD are the delivery mechanism rather than an add-on, on the assumption that we will not be the ones maintaining what we build in three years — which is also why we build it the way the method below describes, rather than the way that is fastest to walk away from.
What we build
- Internal line-of-business applications that run a process nothing off-the-shelf handles.
- Integrations with no off-the-shelf connector.
- Customer-facing data products and portals.
- Reporting APIs.
The handover standard
handover standard · six commitments, all six required
- Repository ownership. The code is in your source control from the first commit, not delivered as an archive at the end.
- Documentation written for the next engineer, not for the invoice.
- A deployment pipeline your team can run without us.
- A runbook for what actually happens when something breaks.
- A knowledge-transfer session with the people who now own it.
- Role-based access control and audit logging as part of the build, not an add-on quote.
When you should not build
Sometimes the right answer is not to build. If a product already does what you need, we will point you at it instead of billing for a worse version of it. If the real problem is a process, not a missing system, fixing the process is often cheaper and faster than software — and we will say so.
The proof is this site
dogfooding · Static Web Apps case study
This website is built and deployed exactly the way we build for clients: source control from the first commit, code review, and an automated deployment pipeline. The Static Web Apps case study walks through the architecture, the CI gates and the real monthly run cost — the one part of our work you can inspect before hiring us.
illustrations · shape only — no client named
The shapes this usually takes: a lender that needs branch staff to see one customer view instead of three; a grocery group whose ordering tool lives in a spreadsheet; a 3PL whose client portal is six emails a day. These are illustrations of shape, not clients — we have no client work we are permitted to describe, and /case-studies/ publishes none.
What this silo covers
How we build
Source control from the first commit. Every project starts in a repository, not a folder on someone's laptop.
Review on every change. Nothing ships without a second pair of eyes on the diff.
Automated deployment. A pipeline builds and deploys the same way every time — the same pipeline this site itself ships through.
Tests where a defect costs money. Coverage is targeted at the parts of the system where being wrong is expensive, not a percentage target for its own sake.
Documentation for the engineer who inherits it. Written for whoever owns this in three years, not for the invoice.
Built for
- The tool that fills the gap between two products you already own, and nothing off-the-shelf handles.
- An internal application running a process specific enough that a generic product does not fit.
- A data product you want to put in front of your own customers.
- A team that wants to own the result afterward — the code, the pipeline, and the decisions behind them.
Not a fit
- What you need already exists as a product — we would rather tell you that than build a worse version of it.
- You want a body shop adding headcount to your team indefinitely, with no handover in view.
- The real gap is a connection between two systems you already run, not a new one — see Automation & Integration.
- You need a large, multi-year platform build — a different shape of engagement than this team is set up for.
Source control, review and access practices for this work follow the same standard described everywhere else.
Start with a call about what you are trying to fix.
Book an assessment call30 minutes · with the engineer who would scope the work
one-page recap within 2 business days of a call that progresses