Custom software development for growing firms.

Who this is for

Custom software is rarely the first answer. We're a fit when one of three situations is true:

1. You've outgrown an off-the-shelf tool. You're paying per-seat for software you've bent into shapes it wasn't built for. The workarounds have workarounds. The thing you actually need would be cheaper to build cleanly than to keep paying for and patching.
2. You need an integration nobody else will write. Two systems your team uses every day don't talk to each other, and the SaaS vendors aren't going to fix it. A small, well-scoped middleware service in the right place collapses hours of weekly work.
3. You're prototyping a product idea. The business has a product hypothesis and needs a working prototype to test it — fast, cleanly built, and easy to throw away if the hypothesis turns out wrong.

If the answer is just "we want a website" or "we want a mobile app" without a hypothesis behind it, we'll tell you to step back and refine the question. We build software with a job to do.

What we build

Internal tools & admin interfaces

The unglamorous engine room of a growing firm: client portals, intake forms, deal trackers, matter management, custom dashboards, role-based admin panels. Built on a modern web stack that your team can actually use on a phone if they need to.

APIs & integrations

Two-system bridges, webhook handlers, ETL pipelines, queue-based workers. Done with proper retries, dead-letter handling, and observability — the operational hygiene that's the difference between a script that "works" and a system you can rely on at scale.

Prototypes & MVPs

Built for clarity over completeness. We're explicit upfront about what the prototype is testing, what it deliberately doesn't do, and how to graduate it to production cleanly if the hypothesis holds.

Production web applications

Client-facing applications with proper authentication, data isolation, audit logging, and a CI/CD pipeline. We are particular about the boring parts: error handling, retries, backups, alerting, runbooks. The boring parts are what separates a system you trust from a system you have to babysit.

Tech stack

We work with mainstream, well-supported technologies because operational fit matters more than novelty:

We're not married to any single combination. For a static brochure site we'll ship a Cloudflare Pages build. For a multi-tenant SaaS we'll ship something with a real database, real auth, and real observability. The choice is made during scoping, in writing, with the reasoning explicit.

Engineering practice

How we work, technically, on every project:

How an engagement runs

1. Discovery (free, 30–45 min). What you're trying to build, what's blocking it, what success looks like.
2. Scoping brief (1 week, paid). A one-page document: build/buy/defer recommendation, proposed architecture, milestone breakdown, fixed price, target dates, and risks. Yours to keep whether you proceed or not.
3. Delivery (2-week cycles). Each cycle ends with a working demo on real data. You can pause or stop between cycles — never trapped mid-build.
4. Handover. Source code, credentials, runbooks, and documentation transferred to your team or to whichever party you nominate. You can take ownership cleanly.
5. Optional retainer. If you want us to keep operating it, we will — typically as part of Managed Tech Partner. If you'd rather take the keys, take the keys.

Pricing

Project work is priced as fixed-fee per milestone. After Discovery, the scoping brief contains a milestone breakdown with target dates and fixed prices for each. You approve milestones before they start. Change requests are scoped and priced as their own milestones — never absorbed silently, never billed by the hour. The Discovery itself is free; the scoping brief is paid (a flat fee, credited toward the project if you proceed).

Handover & ownership — designed to be replaceable

Every system we build is structured so a different engineering team can take it over without losing weeks. That's the test we hold ourselves to: could another senior engineer come in and ship a fix tomorrow without us in the room? If the answer is no, we haven't documented enough.

What we won't build

• Software you don't actually need yet — we will tell you when "wait six months" is the right answer.
• Vanity rebuilds of working systems. We don't get paid by the rebuild.
• Systems whose primary purpose is to circumvent a vendor's terms of service or a legal obligation.