Custom Development

What we actually build

The phrase "custom development" gets used to sell everything from a WordPress theme to a 50-developer SAP migration. We do not do either. We build:

• B2B SaaS products — dashboards, internal tools, vertical SaaS for niche operations.
• Operations platforms — dispatch, scheduling, fulfillment, AP/AR, document intake. See MeatLogix for an example.
• Customer-facing apps — web and mobile with auth, billing, push, offline, payment.
• Power Apps + Dataverse — when Microsoft Power Platform is the right call.
• Marketing sites + CMS — including the site you are reading right now.
• Hybrid — web + mobile + integrations + agents, when the product needs all four.

We do not typically take on:

• Pure UI redesigns with no backend or product work.
• Themes / templates / template implementation.
• WordPress / Wix / Squarespace builds.
• Single-page "brochure" sites with no functional requirements.

How we pick the stack

The biggest mistake we see in agency-built products is technology chosen because someone on the team wanted to use it. We pick per project, based on four questions:

1. Where will this run, and who maintains it? If your team uses Microsoft 365 and your IT will only sign off on Azure, custom Node.js on AWS is a non-starter.
2. What is the actual user surface? Web, mobile, internal tool? Tablet-first or desktop-first? Online or offline-tolerant?
3. What integrations dominate the architecture? Microsoft-heavy points to Power Platform; SaaS-heavy points to TypeScript on Firebase or Supabase.
4. What does the operational reality look like in a year? Will you own this in-house or pay us to operate it? Pick the stack the long-term operator can actually run.

Our common defaults:

Production-grade is not optional

Most "MVPs" that fail in production fail because they were never actually production-grade. They were demos that got pushed live. We treat production-grade as table stakes, not as an add-on. Every product we ship includes:

• Authentication — email, OAuth (Google, Microsoft), magic links, or SSO via SAML/OIDC where the customer needs it.
• Authorisation — proper role-based access control, not "everyone is admin."
• Audit logs — who did what when, server-side recorded, queryable.
• Billing — when applicable, via Stripe with proper webhook handling, idempotency, retries, and dunning.
• Email — transactional via Resend or Postmark, templated, deliverability-tuned.
• Observability — Sentry for errors, structured logs, dashboards.
• Tests — unit, integration, e2e where it pays back. We do not test for the sake of testing.
• Accessibility — WCAG AA minimum, ARIA where it adds value, keyboard nav, screen-reader passes.
• Performance — Lighthouse > 90 on relevant routes. LCP < 2.5s. CLS < 0.1.
• Deploy pipeline — CI/CD on every push, preview environments per PR, one-click rollback.
• Runbook — what to do when it breaks.

If we skip any of these we tell you we're skipping it and why.

Our process

Discovery — 1 to 2 weeks

We sit with the operational owner, the technical owner, and (where possible) two or three real future users. We map the product idea against the four stack questions above. We identify the riskiest assumptions and the cheapest experiments to validate them. We write a product spec — not a 50-page PRD, but a clear scope document including non-goals.

Prototype — 3 to 4 weeks

A working slice on real data with thin scaffolding. End-to-end, but only for the happy path. Real auth, real database, real backend. The prototype gets shown to real users; we adapt based on the feedback before committing to the full build.

MVP — 6 to 12 weeks

Production engineering. All the table-stakes items above. Roughly 80% of the planned feature surface, in deployable slices. The MVP goes to a controlled cohort first — usually 10 to 50 users — before opening up.

Iterate — ongoing

Weekly or biweekly releases. Continuous improvement on metrics that matter. Quarterly architecture reviews. We can keep building on retainer or hand off cleanly to your team.

Our opinions, briefly

TypeScript everywhere. Type safety end-to-end is the single biggest productivity multiplier we have ever experienced. We will not build a product in untyped JavaScript or Python unless there is a strong reason.

Server components over SPA-everywhere. Next.js App Router with React Server Components is the default. We use client components only where interactivity demands them.

SQL-first for relational data, NoSQL for everything else. Postgres for relationships, transactions, joins. Firestore for documents, realtime, offline-friendly. Both can be right; the answer is rarely "MongoDB."

Tailwind + shadcn/ui for design systems. It is not the fanciest stack. It is the one we and our clients can maintain in two years without remembering anything.

Power Platform for Microsoft-heavy orgs. It moves fast for the right shape of problem. Our PowerApps to production post covers where it stops working.

Pricing — the honest version

We bill weekly during the build for transparency. You see exactly what you are paying for, and you can pause the engagement at any phase boundary.

What we will not do

• Take on a project where the customer cannot articulate the problem they're solving.
• Quote a multi-month build from a one-hour intro call.
• Build a product on a stack the operating team can't run.
• Skip auth, audit logs, or observability because the timeline got tight.
• Cargo-cult the latest framework just because it shipped this quarter.

If you have an idea that needs technical work and you want a fast take on the right shape, send a note. One paragraph is enough. We respond within one business day.