App Development

App development for the work off-the-shelf can't do.

When no product fits how your business actually runs, I design and build the tool that does — built around your workflow, integrated with your stack.

Book an intro callLog into a live demo

The build is the easy part.

Custom software fails on the things nobody demos: whether the workflow was modeled the way it actually runs, whether your team can operate the result without me, and whether anyone said no to the features that hadn't earned their place.

Yours to run

Runbooks, not dependence.

The tool isn't finished when it works. It's finished when your team can operate it, explain it, and change it without booking time with me.

  • Runbooks and written docs at handoff, plus live training
  • Your cloud account, your database, your repository
  • No retainer required to keep it running

The honest no

What I won't build.

Most custom-software budgets die on features that sounded essential in a kickoff and got opened twice. Some proposals deserve a no before they cost you a quarter.

  • A tool that duplicates software you already pay for
  • A rebuild of a spreadsheet that was working fine
  • Features that demo well and then go unused
Ops console

Internal tools

Where the spreadsheet gave up.

The A/R tracker, the ops console, the approval flow — modeled properly, with permissions and an audit trail instead of tab-color conventions. Artist House runs an A/R workflow no off-the-shelf product fit: several platform APIs stitched into one tool, replacing the manual cross-referencing between systems.

  • Admin panels and ops consoles shaped to your workflow
  • Roles, permissions, and audit history built in
  • Automations attached where the manual steps were
Artist House · in production
instead of three logins and a spreadsheet
One tool
attributable, with an audit trail
Every change
Customer portal

Customer-facing

Where your clients log in.

Portals and dashboards that put orders, documents, and account data in your customers' hands — without support tickets doing the routing. Zemvelo's D2C portal is in development on exactly that pattern: account data and order history the customer checks for themselves.

  • Customer and document portals with secure authentication
  • Status timelines your customers check instead of emailing about
  • Installable PWAs when app-store distribution isn't worth the tax
Zemvelo · in development
instead of a support thread
Self-service
and the customer sees it
One update
Pipeline

Custom CRM & systems of record

The system your business actually runs on.

When the CRM doesn't fit the pipeline and the records live in four places, the fix is usually one system that owns them. Mineralife's custom CRM is fed by the marketing site — lead capture through to sales pipeline in one place, under an ongoing retainer.

  • Records modeled around your pipeline, not a vendor's
  • Fed by the site, the store, and the platforms you already run
  • Reporting on your data as it actually is
Mineralife · in production
lead capture through to pipeline
One system
on a workflow you own
No seat licenses

Whichever way you start.

Build the tool that doesn't exist

You've searched; nothing fits. The workflow becomes the spec.

Build on what you run

The data already lives in your CRM, your store, your books. The app goes on top, through their APIs.

Rebuild the one that's straining

The aging database app or the macro-driven spreadsheet, rebuilt on a modern stack — data migrated, ceiling gone.

Available on retainer or by project — same discipline either way.

How retainers work →How projects work →

From workflow to working software.

  1. Step 1

    Discovery

    Map the workflow as it actually runs — every step, every exception, every workaround.

  2. Step 2

    Architecture

    Data model, roles, integrations, and stack — a blueprint you approve before code.

  3. Step 3

    Build

    Staged releases tested on real data and real edge cases, not happy-path demos.

  4. Step 4

    Handoff

    Runbooks, docs, and training — your team operates it without waiting on me.

Tooling
  • Next.js
  • React
  • TypeScript
  • PostgreSQL
  • AWS Lambda
  • Amazon S3
  • Amazon RDS
  • Amazon Cognito
  • REST & GraphQL APIs
  • React Native

Live demos

Don't take my word for it — log in.

Two working demos. Real screens, fake data, open credentials, no signup. Take them for a spin — these are the floor; together we can shoot for something with much taller aspirations.

How pricing works.

Three ways to engage, and a fixed number agreed before any of them starts — scope settled before code, not discovered halfway through it.

Blueprint

Fixed fee

Your workflow mapped end to end, then modeled: data, roles, integrations, and screens. The scoping step that tells you what the tool costs to build — before you commit to building it.

  • The workflow documented, exceptions and workarounds included
  • A data model, roles, and integration plan you approve
  • Yours to keep — whoever ends up building it

Project

Fixed price, milestone-based

The build, with the scope and the number agreed before anything starts. A focused internal tool typically lands in 6–10 weeks; a customer portal or multi-role application runs longer.

  • Staged releases tested on real data and real edge cases
  • Milestones you sign off on as they land
  • Runbooks, docs, and training at handoff

Retainer

Monthly

Standing engineering capacity after launch — for the tool that keeps growing into more of the workflow, which is what happens when one finally fits.

  • A predictable monthly block of work
  • Priorities you set, re-set whenever they change
  • Cancel or pause between months

What moves the number

Bring the workflow — or the spreadsheet standing in for it — to a 30-minute call and you'll leave with a real range, not a proposal you have to chase.

  • How many roles and screens the tool needs
  • Whether the data model exists or has to be designed
  • How many systems it has to integrate with
  • Whether data has to migrate out of what you run now

Frequently Asked Questions

When does a custom app beat off-the-shelf software?

When the workflow is your edge — or your bottleneck. If you're contorting a product to fit, paying for seats you don't use, or running the real process in a spreadsheet next to it, a purpose-built tool usually costs less than the workaround.

What stack do you build on?

Next.js and React with TypeScript, PostgreSQL for data, and serverless AWS — Lambda, S3, RDS, Cognito — so the infrastructure scales with use instead of idling on a server bill.

How long does a custom app take to build?

A focused internal tool typically lands in 6–10 weeks; a customer portal or multi-role application runs longer. You get a scoped blueprint with milestones before the build starts.

Can it connect to the systems I already use?

That's assumed, not extra. Most tools I build exist to sit on top of a CRM, storefront, or accounting platform — integration is the foundation, not a bolt-on.

Do you build mobile apps?

For most business tools, a responsive web app or installable PWA covers phones without app-store overhead. When a true native app is warranted, I build cross-platform with React Native — iOS and Android from one codebase.

Who maintains the app after launch?

Your call. Everything ships with documentation and runbooks so your team can operate it. Most clients keep me on retainer for changes and new features as the tool grows into more of the workflow.

Tell me about the spreadsheet.

Every custom tool starts as a spreadsheet somebody's tired of. 30 minutes — bring yours, or the workflow that's outgrown it, and you'll leave with scope, approach, and a straight read on fit.

Book an intro call