// web application development

Not a prettier homepage. The web app your customers use.

The customer portal, the quoting and booking tool, the client dashboard, the marketplace, the SaaS-style product your business runs on. We build the real application, wired into the accounting, inventory, and CRM systems behind it, so what your customers do online flows straight through instead of landing back in someone's inbox.

wired to your systems · quoted, not open-ended · you own it
A schematic web application: a customer portal screen wired to the back-office systems behind it.
// where it breaks down

Your customers are inside a process built for staff.

Customers, meet the spreadsheet.

The operation ran on email and shared sheets when it was just your team. Now customers are in the loop, and they see every handoff, delay, and dropped thread.

No portal, so the phone rings.

Customers call to ask where their order, quote, or request stands, because there's nowhere to look it up. Answering the same question all day became somebody's job.

The SaaS almost fits.

The off-the-shelf product covers most of it, then forces a workaround for the part that is your business. The manual steps around it are quietly eating the savings you bought it for.

A pretty site that does nothing.

An agency delivered a good-looking homepage and a contact form. It doesn't quote, book, track, or transact, and none of the real work ever moved online.

One person can touch the app.

The web app that carries a slice of your revenue was built years ago by someone who's gone. Every change is a gamble, so nobody makes one, and it slowly falls behind the business.

The demo worked. Real users didn't.

An AI-built prototype looked great in the pitch, then buckled on real accounts, real data, and real load. It's live now, and fragile, and everyone's holding their breath.

// how we build it

Web applications built to carry real work.

Not a design mockup with a login bolted on. We scope the product around the actual workflow, build it on technology that holds up, ship it to production for real, and put it in your hands.

  1. 01

    Scope The Product Around The Workflow

    NOT SPEC THEATER

    We start from the job the app has to do and the people who'll use it, your customers and your staff, not a hundred-page requirements document nobody reads. We map the real workflow: the states a quote or an order moves through, and the edge cases that live in someone's head.

    You come out with a scope you can see and a fixed quote against it before any code, so you're buying a defined thing, not funding a research project.

    WHAT YOU WALK AWAY WITH
    • A scoped product: the screens, the flows, and the states the app has to handle
    • A fixed quote against that scope, approved before we build
  2. 02

    Build On Boring, Proven Technology

    WIRED TO YOUR SYSTEMS

    We build on stacks that have run in production for years, not whatever's trending, so the app stays maintainable long after we're gone. The point isn't novelty, it's software that holds up under real customers.

    And it doesn't stand alone. We wire it into the systems behind it, your accounting package, CRM, inventory, and payment processor, so a booking, quote, or order flows straight through instead of being re-keyed by hand.

    WHAT YOU WALK AWAY WITH
    • An application built on proven, maintainable technology, not a framework someone picked up last year
    • Integrations to the back-office systems that carry the work
  3. 03

    Ship It To Production For Real

    AUTH, ROLES, AUDIT

    A customer-facing app is only real once it handles real accounts, real security, and real data. We build proper authentication, roles and permissions, and an audit trail, and we test it against the load and the failure cases a demo never sees.

    This is the part design shops and AI prototypes skip, and it's exactly where they break. We treat it as the actual work, not an afterthought.

    WHAT YOU WALK AWAY WITH
    • Authentication, roles, and permissions built for real users
    • An audit trail, plus testing against real load and the edge cases
  4. 04

    Hand It Over

    OWNERSHIP & SUPPORT

    We document what we built, train the people who'll run it, and put the whole thing in your accounts: the code, the database, the domains, the credentials. Support is a contract or as-needed, your call.

    Either way the application is yours, built so any competent engineer can maintain it, and it keeps running whether or not we're in the picture.

    WHAT YOU WALK AWAY WITH
    • Documentation and training, with everything in your accounts and your name
    • Full ownership of code, data, and infrastructure, with no lock-in
A customer-facing app connected to the accounting, inventory, and CRM systems that carry the work.
// why bring us in

Senior engineers who've shipped at scale.

  • We've built apps that carried millions of users.

    The team behind this shipped a podcast platform to 32 million monthly users, internal applications serving 30,000 people a day inside a Fortune 500 healthcare company, and payment systems under PCI-DSS. Consumer-scale production software is work we've done, not a promise we're making.

  • We'll tell you when off-the-shelf SaaS wins.

    If a product covers what you need, that's our recommendation, even though we make nothing on it. We build a custom application only when the workarounds have started costing more than the software they're patching around.

  • Quoted work, no open-ended billing.

    A defined build is a fixed quote you approve before we start, and changes are quoted, never quietly billed. When the scope is still being discovered, we work hourly against a cap you set, then convert to a fixed quote once the ground is known. No project that balloons past the point you'd have stopped.

  • US-based, and you own it all.

    The people who scope your app build it, every one a US citizen working in the US. The code, database, domains, and accounts land in your name from day one, built for any engineer to maintain, with no lock-in.

// questions

Before you build the app.

What's the difference between a website and a web application, and which do we need?

A website tells people about your business: pages, images, a contact form. A web application is software your customers or staff actually do something in: log in, get a quote, book a slot, check status, place an order, read a dashboard. If a design shop can build what you're picturing, you probably want a website, and we'll say so rather than sell you more than you need. If the thing has to log people in, hold their data, and talk to your other systems, that's an application, and that's what we build. On the intro call we'll tell you plainly which one your problem is.

What does a web application cost?

For a defined build it's a fixed quote, given after the free intro call and locked before we start. We don't publish a number because a single customer portal and a full SaaS product aren't the same job. You approve the scope and the price before any code, and changes are quoted rather than billed into a growing invoice. When a flat rate doesn't make sense, because the scope is still being discovered or the work is genuinely exploratory, we work hourly against a cap you approve and move to a fixed quote once it's known. Ongoing support runs as a retainer sized to your operation. What you never get is open-ended billing.

Can you take over or fix an application we already have?

Yes, and it's a big part of what we do. Whether an agency built it, a developer who's since moved on, or an AI tool that looked great in a demo and buckled on real users, we can assess it, stabilize it, and take it forward. If your app is already live and breaking under real accounts, real data, or real load, that's exactly what our rescue engagements are for: we triage what you have, harden it for production, and get it maintainable again. No judgment about how it was built, and NDA-friendly.

What do you build on, and where does it run?

Boring, proven technology: the languages, databases, and clouds that have run production systems for years, not whatever framework is trending this quarter. It runs in your cloud accounts, on your domains, under your credentials, so there's no platform of ours you're renting and no switch we can flip. You own the whole thing, and any competent engineer can pick it up. Where it makes sense we match the stack to what you already run, rather than making you adopt ours.

Do you handle design and UX, or only engineering?

Both, in the measure the app needs. A customer-facing product has to be clear and pleasant to use, so we design the screens and the flows, not just the code behind them. We're an engineering firm first, so the design serves the work: no beautiful mockup that can't be built, and no interface that adds clicks to finish a task. If you already have a designer or a brand, we'll build to it instead of reinventing it.

// let's scope the app

Tell us what your customers need to do.

Thirty minutes over Google Meet, no prep. Walk us through the process your customers or your staff are stuck doing by email and spreadsheet, and we'll tell you what belongs in a real application, what an off-the-shelf product would handle for less, and where we'd start.

Based in the South Bay of Los AngelesOn-site across LA & Orange CountyRemote clients welcome
SCHEDULE DIRECTLY
Chris Hayes, founder of AmiFi
Chris Hayes
Founder & Principal Engineer

Book straight onto Chris's calendar. No sales rep and nothing to prepare: you talk with the engineer who would actually scope the work.

ON THE CALL
  • Where your team's hours actually go.
  • What's worth automating, and what isn't.
  • A concrete next step, or an honest no.
30 MINGOOGLE MEETFREE
Pick a time
Opens our Google Calendar in a new tab.
OR SEND A NOTE
PREFERRED CONTACT
We reply within one business day.