Skip to content
Custom micro-SaaS applications

Software shaped like your business, not the other way around.

A micro-SaaS is a small, focused, multi-user application that does one job for your company exceptionally well. Three to eight screens that replace a process. You own the code, the infrastructure, and the roadmap.

Two developers sharing one screen while working through code together
Build vs buy

Most companies should buy. Some shouldn't.

We build custom software for a living, which should make you appropriately skeptical of our opinion here. So here's the honest version — including when to go with the vendor.

Buy off-the-shelf when…

  • Your process matches how the industry does it
  • The vendor's roadmap points where you're going
  • Configuration gets you to 90% without custom code
  • You have no appetite to own software long-term

Build a micro-SaaS when…

  • Your process is the competitive advantage
  • You're paying for 40 modules and using three
  • Every vendor demo ends with "we could customize that"
  • The workaround spreadsheet has become the real system
  • Seat licenses now cost more than a build would amortize to

What's in a build

Every application ships with these. They aren't upgrades or phase twos.

Multi-user from day one

Roles, permissions, SSO, and an audit trail. Not a spreadsheet with a login screen bolted on.

Integrated with what you run

Your ERP, CRM, accounting, file store, and messaging. The application lives inside your stack, not beside it.

AI where it earns its place

Extraction, classification, drafting, prediction — added after the workflow works, with an eval set proving it helps.

Mobile when the work is mobile

Offline-capable field interfaces for people wearing gloves in a parking lot with one bar of signal.

Deployed on your cloud account

Infrastructure as code in your AWS, GCP, or Azure tenancy. You hold the keys and the bill.

Documented for the next person

Architecture decision records, runbooks, and a training session for whoever inherits it.

A small team working together around a meeting table with laptops and printed documents
How a build runs

Ten to fourteen weeks, demoed every Friday

No nine-month reveal. You see working software from week three and can change direction while changing direction is still cheap.

01 · Week 1–2

Shape the product

Interviews with the people who do the work today, a map of the current process, and a written product definition: who uses it, what job it does, and what we are deliberately not building.

  • Process map
  • Product definition
  • Clickable prototype
  • Fixed build quote
02 · Week 3–8

Build the spine

The core workflow end to end — data model, the one path that matters, and the integrations it depends on. Real data in a staging environment by week five, and a demo every Friday.

  • Working application
  • Integrations live
  • Staging with real data
  • Weekly demos
03 · Week 6–10

Layer in the AI

Extraction, classification, drafting, or prediction — added once the workflow is proven, with an evaluation set so you can see whether it's helping. The application works without it; the AI makes it fast.

  • Eval test set
  • Confidence thresholds
  • Escalation rules
  • Cost model
04 · Week 9–12

Roll out and hand over

Pilot with one team, fix what the pilot finds, then widen. You get the repository, the infrastructure, runbooks, and a training session for whoever owns it next.

  • Pilot & rollout plan
  • Runbooks
  • Source & infrastructure
  • Team training
Ownership

You own it completely. That’s the whole point.

Source code in your repositories from the first commit
Infrastructure as code in your own cloud account
No license, no per-seat fee, no escrow arrangement
Support retainer optional and cancellable any month
Multi-tenancy built in where it's plausible you'd sell it later
When we say no

A micro-SaaS isn’t right for

  • A consumer app or marketplace looking for product-market fit
  • A full ERP or CRM replacement
  • Anything where the requirements can't be pinned down in two weeks
  • Projects where the budget is under $60k — a good no-code build serves you better

If you describe one of these, we’ll say so on the first call and point you somewhere better.

Micro-SaaS questions

The things every prospective client asks in the first thirty minutes.

What exactly is a micro-SaaS application?

A small, focused, multi-user web application that does one job for your business extremely well — quoting, dispatch, review, intake, reconciliation. It's not an enterprise platform and it's not a spreadsheet with a login. Think 3–8 screens that replace a process, owned by you rather than licensed.

Do we own the code?

Completely. Source, infrastructure definitions, CI pipelines, and documentation are yours in your repositories from the first commit. There is no license, no per-seat fee to us, and no escrow arrangement — you already have it.

What does it cost to run after launch?

For a typical application in this range: $300–$1,500/month in cloud infrastructure, plus AI model usage that usually lands between $50 and $600/month depending on volume. We model your specific numbers during scoping so there are no surprises.

Can our own developers maintain it?

That's the design goal. We build with mainstream, boring technology — TypeScript, React, Postgres — and document decisions as we go. If you don't have developers, we offer a support retainer, and you can end it whenever you like.

How is this different from a no-code tool?

No-code is excellent up to a ceiling. Past it — real permissions, complex business rules, performance at volume, integrations that need to be reliable — you end up fighting the platform. We often build alongside your no-code tools rather than replacing them.

What if we want to sell it to other companies later?

Several clients have. Because you own the code outright and we build multi-tenancy in when it's plausible, turning an internal tool into a product is a business decision rather than a rewrite. We'll flag the design choices that keep that door open.

Scope an application

Describe the process. We’ll tell you if it should be software.

Sometimes the answer is a two-week automation instead of a build, or a product you should just buy. You’ll get a straight read either way.

Helpful to include
What the process is and roughly how often it runs
Which systems it touches today
How it's handled now — tool, spreadsheet, or person
What you've already tried or evaluated

We use your details to reply to this request only. No sequences, no list.

Taking two new engagements this quarter.