The spreadsheet that runs the business
A critical process lives in a workbook with no access control, no history, and no validation. We turn it into an application with permissions, an audit trail, and reporting.
Engineering Practice
Custom Application Development
Software built to be owned, not rented. Multi-tenant SaaS, internal operational tools, and the integrations between systems that were never designed to talk to each other.
What this service actually is
We build the applications that off-the-shelf software cannot cover. Usually that is because the business has a process that is genuinely its own: a distribution workflow, a compliance obligation, a pricing model, a chain of custody. The available products handle 70 percent of it, and the remaining 30 percent gets absorbed by spreadsheets, email threads, and one person who knows how it really works.
The practice covers the full arc: product definition, data model, interface, integrations, deployment, and the operational tooling to run it. We have shipped multi-tenant SaaS platforms in logistics and cannabis operations, online voting and compliance systems for member organizations, an AI voice assistant, and internal interfaces sitting on top of third-party fulfillment APIs. The common thread is that each had a real user population and had to keep working after we left.
Two things distinguish this from a typical agency build. The first is that security is part of the architecture rather than a scan at the end: tenancy isolation, row-level access, audit trails, secret handling, and authorization boundaries are designed in week one by a CISSP- and CISM-certified practice. The second is that we optimize for the maintenance decade, not the launch date. That means boring, well-documented technology choices, tests around the parts that carry money or compliance risk, and infrastructure defined as code.
We also take over stalled and inherited codebases. That work starts with an honest assessment: what is salvageable, what should be rewritten, what the real risk exposure is, and what it would cost either way. Sometimes the answer is that a rewrite is cheaper than continuing, and we will say so directly.
The problems we are usually hired to solve
Systems that do not talk
Orders in one platform, inventory in another, accounting in a third, reconciled by hand. We build the integration layer, including idempotency and reconciliation reporting.
Multi-tenancy done wrong
A product sold to multiple customers with tenant separation enforced only in application code. We design isolation at the data layer where it actually holds under a bug.
An inherited codebase nobody understands
The original developer is gone, there are no tests, and deployment is a manual ritual. We document, stabilize, add coverage where risk concentrates, and automate release.
A prototype that cannot scale
It worked for 20 users and fails at 2,000. We find the real bottleneck rather than guessing, and fix the architecture instead of adding servers.
Compliance requirements bolted on late
Audit trails, retention rules, and consent tracking retrofitted into a schema that cannot express them. We design the data model to carry those obligations from the start.
How an engagement actually works
- 01
Product definition and constraints
We start at the whiteboard, not the editor. Who the users are, what each one must accomplish, what the system must never allow, what it integrates with, and what compliance or contractual obligations the data carries. The output is a written scope with an explicit list of what is out of scope for version one, which is the part that actually protects the timeline.
- 02
Architecture, data model, and threat model
The data model gets designed before any interface work, because it is the decision that is most expensive to reverse. Tenancy strategy, authorization boundaries, audit and retention requirements, and integration contracts are settled here, alongside a threat model covering authentication, authorization bypass, injection, and data exposure.
- 03
Iterative build with working software every two weeks
You see and use running software on a fixed cadence, in a real environment, from early in the project. Automated tests concentrate on the paths that carry money, compliance, or destructive operations. Infrastructure is defined as code, and every environment is reproducible from the repository.
- 04
Hardening, data migration, and launch
Before launch: load testing against realistic volume, dependency and vulnerability review, backup and restore actually exercised rather than assumed, monitoring and alerting configured, and a rehearsed migration for existing data. Launch is staged where the risk profile calls for it, with a documented rollback path.
- 05
Handoff or ongoing ownership
You own the repository, the infrastructure definitions, the documentation, and the runbook, on your accounts. From there, some clients take the system in-house, some keep us on a maintenance and enhancement retainer, and some use us as fractional engineering leadership while they hire. All three are supported; none of them require us.
What you receive
The application, in your accounts
Source in your repository, infrastructure as code in your cloud tenancy, domains and secrets under your control. Nothing is hostage to our continued involvement.
Documented architecture and data model
Schema documentation, integration contracts, authorization model, and the reasoning behind the significant technical decisions, so the next engineer inherits context.
Automated test coverage where it matters
Tests around authentication, authorization, financial calculations, destructive operations, and compliance-relevant paths, running in continuous integration.
Deployment pipeline and environments
Reproducible staging and production environments with automated deployment and a rehearsed, documented rollback procedure.
Monitoring, alerting, and runbook
Error tracking, uptime and performance monitoring, and a written runbook covering what each alert means and what to do about it.
Security review documentation
Threat model, dependency posture, secret-handling approach, and audit-trail design, in the form an enterprise procurement or insurer review will accept.
Who this is for
Operating companies with a unique process
Distribution, logistics, cannabis, property management, and member organizations where the differentiating workflow is not something you can buy.
Founders building a SaaS product
Where the first version has to be credible to enterprise buyers on security and multi-tenancy, not just functional in a demo.
Teams with an inherited system
A codebase you now depend on and do not fully understand, where you need an honest assessment before deciding to invest or replace.
Frequently asked questions
Related services
Describe the process software should be doing.
Bring the workflow, the spreadsheet, or the inherited codebase. You will get a straight answer on scope, cost, and whether building is the right call at all.
Start a conversation