When a website is not the thing that is broken.
Some work does not fit a page and does not fit a bot. It is the spreadsheet three people edit at once, the two systems somebody reconciles by hand every month, the process that lives in one person's head. That is an application, and we build those.
We build them the same way we build everything else: the structure is signed off before the code, the data stays in a schema with your name on it, and anything consequential waits for a human.
Three shapes.
Internal tools and CRMs The system your team works inside all day. Records, states, permissions, and the reports someone is currently rebuilding in a spreadsheet every Monday.
Customer-facing web and mobile apps What your customers, members, or tenants log into — bookings, accounts, requests, status. Web, or web plus a phone app where the work happens away from a desk.
Multi-system integrations Two systems that hold overlapping truth and are reconciled by hand. We build the bridge, agree what wins when they disagree, and make the reconciliation a job rather than an afternoon.
Discovery → Blueprint → Build → Handover.
- Discovery. We learn the workflow: what triggers it, what it produces, where a human has to decide, and what systems it already touches.
- Blueprint. A signed-off artifact before anyone writes code — the state machine, the human gates, the integrations, and the acceptance criteria. You approve it. Changes at this stage are free; changes after a build is coded are not. [DECISION 2026-09-09 — Darrin: "publish as written." The Blueprint ships as a named, signed-off deliverable.]
- Build. Written against the Blueprint, in slices you can see working rather than one delivery at the end.
- Handover. The running system, the schema, the deployment, and the documentation. You own the data and you can export it.
What we build on.
Two things are true of everything we run, and they are the two that matter to you:
Your data sits in its own schema. Every tenant gets a named Postgres schema, scoped at the connection level rather than filtered in application code. Other customers' data is invisible to your queries by construction. It is the same isolation model the bots use — see how it works.
The service layer is Python and FastAPI. The same stack that runs the public audit endpoint on this site, which is unauthenticated by design and therefore has to be right.
Beyond that we pick the tool to the job rather than the other way round: React and TypeScript on the front end, built with Vite; Supabase where a managed Postgres and an auth layer earn their keep; and a relational database chosen per project. Where an application needs a phone app, we build one — the same team, the same schema behind it.
We name those because we run them. You will not find a framework list on this page that we cannot point at something live for.
Three we have built.
SSA — Solar Service Automation CoreShift's own multi-tenant application for solar field service, and the one place you can see all three pillars in one system. A fault alert arrives from the field, gets dispatched to a technician, and ends as an invoice — one record, one thread, no re-keying between three tools.
Around that run four things the crews actually asked for: an admin interface for the office; an error-code translation layer that turns a manufacturer's fault code into a sentence a technician can act on before leaving the yard; customer management, so the job history sits with the site rather than in an inbox; and parts management, so the truck is loaded against what the fault says is wrong.
It is multi-tenant on the same isolation model everything else here runs on — one schema per tenant, scoped at the connection. Precision Electric is the pilot tenant.
BMG CRM — Baig Medical Group A membership and leads CRM for a concierge medicine practice. Members register through the site or, where they pay by check, are registered by hand. Membership runs across three tiers, and providers get a view of level of care built on top of them. WooCommerce syncs one way into the CRM. No patient health information goes in it — that is a design constraint, not an oversight.
DiegoTech A custom web application for a technology and IT services company: operations, scheduling and dispatch, customer management, project management, and reporting.
Applications are quoted per project against a published menu — internal tool or CRM, customer-facing web app, mobile app, multi-system integration, and a monthly managed run for hosting, monitoring and fixes. Every row has a number on it. See the project menu
Can you work with the systems we already have?
That is usually the job. Most application work we do is a bridge between things that already exist rather than a replacement for them.
Who owns the code and the data?
You own the data, and you can export it — same commitment as every other thing we run. Code ownership is set in the Blueprint before the build starts, so nobody discovers it at handover.
Do we have to take the automation too?
No. The three pillars are bought separately. Plenty of clients buy one and stop there.
What happens after handover?
There is a monthly managed run if you want it — hosting, monitoring and fixes. If you would rather run it yourself, you can; it is your schema and your deployment.