A Working Product, Not a Starter Kit

Most custom software is quoted from an empty folder, which prices the foundations again on every project. Screens get laid out from nothing, navigation gets argued about, and sign-in gets solved for the first time by someone solving it for the first time.

What a build starts from here is a product already in daily use, carrying this practice’s own delivery records and billing. Its structure, screen layout and navigation are the specification, and what changes per customer is the visual appearance and the trade underneath.

That is why the shape of your application is settled in the first week rather than discovered in the third month.

The Week You Do Not Lose

A popup sign-in flow in a modern Angular application can hang with the popup open and the main window still on the login screen, because the popup looks for the original token request in its own storage and the request is in the main window’s.

It was diagnosed here once. Every build since has arrived with the redirect flow already chosen, so nobody spends the week finding it again, and the decision rule sits in the conventions the next project reads before it writes a line.

That is one example of the same pattern: a fix found the hard way becomes a default, and defaults do not appear on an invoice.

You Pay for Your Application

Two applications went from an empty repository to production in about three weeks each, independently, and both arrived with logins, automated tests, a release path and a production database in place.

That is only possible because most of what they needed was not built again. What was built was the part that was genuinely theirs: the rules of the trade, the records kept, the vocabulary, and the screens people open every morning.

The estimate you receive covers that part. The groundwork underneath it was paid for once, by us, on our own business, before any of it was offered to a customer.

It is the difference between a quote that has to cover discovering how software like this should work, and one that only has to cover what your trade actually needs it to do.

3 weeks
from empty repository to production, twice, logins and tests included
1
sign-in defect diagnosed here once, then inherited by every build since
0
mail vendors added: messages go through the tenant you already own
Angular 22
with a signal store, on ASP.NET Core 10 and SQL Server

What Is Already Built Before Your Project Starts

What a Build Starts From 2 steps
01

Start From a Product That Runs, Not a Template

A starter template is a guess about what a project will need. What a build starts from here is a product already in daily use, the one this practice keeps its own books in, so every decision inside it has been tested by someone who has to live with it. Nothing in it is theoretical, because the first user of every mistake was us.
02

Treat the Working Build as the Specification

Copy the structure, the screen layout and the navigation of the proven build, and change only what genuinely differs: the visual appearance, the vocabulary of the trade, and the records the business actually keeps. That turns the riskiest part of a project, deciding how the thing should be shaped, into a decision that was already made and has already survived contact with real use.
What Is Already Solved 3 steps
03

Sign-In Is Settled Before the First Screen

Authentication is where custom projects lose their first month. The base arrives with directory sign-in through Microsoft Entra ID on the front end and audience validation on the API, plus a local account path with roles read from the database, so an account outside the directory still reaches a comparable level without introducing a second identity system.
04

The Release Path Arrives With the Software

Two slots run per application from the first deploy, one serving people and one carrying the candidate version. Promotion retags the image that was already tested rather than rebuilding it, so what reaches production is the artefact that passed. Rolling back is one step on an immutable tag instead of an emergency rebuild at the worst possible hour.
05

Outgoing Mail Uses the Tenant You Already Own

A mail vendor added for one contact form becomes another account, another bill and another place delivery can fail. Confirmations, notices and form submissions go out through Microsoft Graph against a mailbox in your own Microsoft 365 tenant, with application permission and admin consent, so messages carry your domain's real reputation and no separate mail credentials are stored anywhere.
The Fix You Inherit 2 steps
06

The Sign-In Failure, Named Rather Than Alluded To

A popup sign-in flow in a modern Angular application can hang with the popup open and the main window still showing the login screen. The cause is that the popup loads the application, tries to complete the exchange, and finds the original token request sitting in the main window's storage rather than its own. The fix is to use the redirect flow throughout.
07

A Problem Solved Once Is Not Solved Twice

A fix that lives in one developer's memory gets rediscovered at full price on the next project. Each one is written into the conventions the next build reads before it starts, with the symptom, the cause and the decision rule together, so the same afternoon is never spent twice. Hours not spent re-laying foundations are hours that never reach an invoice.
What Is Actually Yours 2 steps
08

What Is Genuinely New Is Genuinely Yours

The part that gets built from nothing is the part nobody else could have built for you: the rules of your trade, the records you keep, the words your people use, and the screens they open every morning. That is where the budget goes, and it is the only part of the work where starting from scratch is the right answer rather than an expense.
09

It Is Running Here Before It Is Quoted to You

Every part of the base described on this page is in production on this practice's own business, carrying its own delivery records, its own billing and its own sign-in. That is the proof available before a customer pays for anything: not a demonstration environment assembled for a meeting, but software whose failures would land on us first.

Frequently Asked Questions

What exactly is already built when a project starts?
The parts every business application needs and none of them wants to pay for twice: directory and local sign-in with roles, screen layout and navigation, a release path with two slots and one-step rollback, end-to-end tests, and outgoing mail through your own Microsoft 365 tenant. On top sits an Angular front end with a signal store, an ASP.NET Core API and SQL Server.
Does that mean we get the same software as everyone else?
No. What is shared is the groundwork, not the product. The structure, screen layout and navigation are inherited, and everything a user would recognise as yours is not: the visual appearance, the rules of your trade, the records you keep, the vocabulary your people use, and the screens they actually open. The base decides how it is built, never what it does.
What was the sign-in problem, in plain terms?
A popup-based sign-in hangs: the popup finishes authenticating but stays open, and the main window never moves off the login screen. The popup is looking for the original token request in its own storage, and that request is sitting in the main window's. Switching the whole application to the redirect flow avoids it, and every build since has started that way.
Can we run this on our own infrastructure?
It is built to be, and here is where that stands. The application is described in files and moves between hosts as a configuration change, and server administration can be handed over with database access scoped to your own data. Both instances in production run on this practice's own infrastructure, so that portability is a design property rather than something a delivery has proven.