§
§ · custom software

Custom software development. For the work your off-the-shelf stack can't do.

Internal tools, client portals, data-integration layers, and greenfield platforms that your existing SaaS stack cannot absorb. Named tech leads, weekly demos, fixed-scope sprints.

§ 01 · when to build

Custom is for the workflow that is your edge.

Most teams should buy SaaS. Commodity workflows (payroll, ticketing, CRM) are cheaper, faster, and better-supported as subscriptions than as custom code. Custom software earns its cost in three places: the workflow that is a competitive differentiator, the integration gap no vendor has filled, and the multi-year total cost where per-seat SaaS pricing crosses the build budget. When two or more of those hold, custom beats buying.

differentiator workflow

Your moat, not a commodity.

Pricing logic, fulfillment rules, underwriting models, matching algorithms — anything where "the way you do it" is part of why customers choose you. SaaS flattens these. Custom preserves them.

integration gap

No vendor connects those two.

A required system has no native connector to another required system, and the gap forces recurring manual work. Zapier-class middleware often patches it, but past 50 monthly runs a purpose-built integration pays for itself fast.

multi-year cost

SaaS cost exceeds build over 3 years.

Per-seat pricing that scales with headcount, usage-based billing that scales with success, or a vendor whose roadmap you do not control. At 50+ seats most mid-market orgs cross this line on at least one SaaS line item.

§ 02 · what we build

Five shapes, one engineering bar.

Most engagements fall into one of five recognizable shapes. Each has a different scope curve, a different risk profile, and a different exit criterion. We price and plan against the shape, not a generic hour bucket.

01

Internal Tools

4-10 weeks

Admin dashboards, ops consoles, internal approval flows, back-office data-entry screens. Low external risk, high leverage; one tool often replaces three spreadsheets and a Slack channel. Retool or Appsmith handle 70% of these faster than custom; we reach for React + Postgres when the remaining 30% requires real interaction or real performance.

02

Client Portals

6-14 weeks

Customer-facing dashboards for reporting, self-service, file delivery, or case management. Higher external risk (customers see the UI), higher trust impact. Auth, audit logs, role-based access, rate limits, and a monitoring plan are non-negotiable from day one; we default to Supabase Auth, Clerk, or Auth0 depending on compliance needs.

03

Integration Layer

4-8 weeks

Purpose-built connectors between systems that no vendor bridges. Two patterns: an event-driven middleware that reacts to webhooks and writes to downstream APIs, and a scheduled ETL that batches transforms on a cron. Both need retry logic, dead-letter queues, and observability. A small investment here eliminates weeks of monthly manual work; the ROI is usually visible in the first quarter.

04

MVP Platform

8-14 weeks

Greenfield products with a real user-facing front end, billing, and the first few must-have workflows. MVPs are about time-to-first-customer, not feature completeness; we cut aggressively on anything outside the 3-5 primary jobs. Stripe for billing, Postgres for state, Next.js for the front end in 8 out of 10 engagements. See our SaaS MVP service for the subscription-specific version.

05

Production Platform

16-28 weeks

Multi-tenant platforms, regulated-data systems, or any product where the first customer is also the first production incident waiting to happen. CI/CD, infrastructure as code, load testing, observability, runbooks, and an on-call rotation are in scope from day one. Slower to ship than MVPs but the floor is much higher; a launched platform without observability is a liability.

§ 03 · how we ship

Weekly demos. Named tech lead. Written scope.

Three operating principles keep engagements predictable. They are not marketing; they are the checkpoints that prevent the class of failure where a three-month project becomes a six-month project becomes a nine-month rewrite.

principle 01

A named tech lead owns the work.

Every engagement has one named senior engineer who attends every call, writes the weekly status, and is accountable for the architecture. No agency-side "account manager" layer between you and the code.

principle 02

Weekly working demo, end of week.

Every Friday a recorded walkthrough of real code in a real environment, with a written what-shipped/what-slipped summary. No weekly demo means no invoice.

principle 03

Scope in writing, change in writing.

Fixed-bid engagements ship against a scoped requirements document. Any change beyond that document triggers a written change request with a cost and a timeline delta — never a silent scope creep.

principle 04

Exit clauses are explicit.

Every contract names who owns the code (you), who owns the infrastructure (you), and what handover looks like if you take the project in-house. No vendor lock-in, no retainer traps, no ownership gray zones.

§ 04 · stack philosophy

Familiar beats fashionable.

Stack selection is driven by three factors, never by framework hype: your team's existing skills, operational cost per month, and hiring availability in your target market. Our defaults are boring on purpose.

layerdefault
Backend languageTypeScript / Python / Go
Web frameworkNext.js / Remix / FastAPI
DatabasePostgres
Cache + queuesRedis
Analytics DBClickHouse / BigQuery
AuthClerk / Supabase / Auth0
BillingStripe
EmailResend / Postmark
DeployVercel / Railway / AWS
ObservabilitySentry + Axiom / Datadog

Postgres handles 90% of the workloads teams think need a specialized database. Redis handles 90% of what teams think needs Kafka. Next.js handles 90% of the web front-ends that founders imagine need custom architecture. Defaulting to boring, mature tools means faster shipping, cheaper hiring, and less operational drama.

We reach for the specialized tool (Kafka, ClickHouse, DuckDB, custom infrastructure) when the boring default provably fails a load test or a business requirement, not before. Architecture decision records document the "why" every time we deviate.

§ 05 · questions

Six answers.

When does custom software make more sense than buying SaaS?

Three conditions usually justify custom software. One, the workflow is a competitive differentiator, not a commodity (buying commodity is correct; building commodity is waste). Two, the per-seat SaaS cost across 3 years exceeds the build cost by a meaningful margin and the vendor controls your roadmap. Three, no SaaS integration exists for a required system and the integration gap forces daily manual work. If fewer than two of these hold, buy. If two or more hold, build.

What does a typical custom software engagement look like?

We start with a 2-week discovery sprint: requirements workshops, system-of-record mapping, architecture decision records, and a scoped fixed-price proposal. MVPs run 8 to 12 weeks with weekly demos and a named tech lead. Greenfield platforms run 16 to 28 weeks across discovery, alpha, beta, and production releases. Retainers are month-to-month for roadmap continuity and incident support. Every engagement has a written scope, a burn-rate dashboard, and a documented exit clause.

Which technology stacks do you work in?

Backend: TypeScript on Node.js, Python on FastAPI or Django, Go for performance-critical services. Database: Postgres primary, Redis for cache and queues, ClickHouse for analytics workloads. Frontend: Next.js or Remix for web, React Native for mobile, plain HTML with progressive enhancement for admin tools. Deploy: Vercel, Railway, Fly, AWS, or the client's existing infrastructure. We pick per engagement on three axes: team familiarity, operational cost, and hiring availability — never chase frameworks for their own sake.

How do you handle data security and compliance?

Every engagement includes a threat model, data-flow diagram, and secret-management audit in the first two weeks. We default to encryption at rest and in transit, least-privilege IAM, and zero hardcoded credentials. For clients in regulated sectors we add SOC 2 Type II gap analysis, HIPAA BAA evaluation, GDPR Article 30 records of processing, or PCI DSS scope reduction as applicable. The OWASP ASVS Level 2 checklist is our default security baseline for non-regulated work.

Can you take over an existing codebase?

Yes. Two-week inheritance audit first: architecture walkthrough with the outgoing team, dependency health check, test coverage review, and a risk register. We then propose either a stabilization sprint (fix the bleeding, add observability, hold the line) or a migration roadmap (incrementally rebuild the critical paths while the legacy system runs). We do not rewrite code for its own sake; we only rewrite what the risk register forces.

What do you charge?

Every engagement is scoped. Discovery sprints run 2 weeks with a fixed price. MVPs and platforms are scoped against a written requirements document with a fixed bid plus an explicit change-request process. Retainers are monthly with a minimum and a cap. We do not publish tiered packages because ranges would be misleading — a 3-screen internal tool and a multi-tenant SaaS platform sit at very different scopes. Book the scoping call; quote lands in 48 hours.

§ 06 · scope it

Scoping call. Quote in 48 hours.

30-minute call to understand the work, the constraints, and the risk. Written scope and fixed-price quote within two business days. No proposal decks, no sales theater.