Built by Full Score
Concertmaster
In the room, guiding, not standing over it.
Concertmaster leads new development. Before a builder, person or AI agent, writes a line of code, it hands them the house rules: where each record lives, what the app may touch, how it should look, and what to record. Then it stays in the room while they build.
It isn't a product we sell. It's how we work, written down as software, and it shortens the road from idea to production. It's a big part of how three people run forty-seven apps.
Why the name
A concertmaster doesn't conduct and doesn't police. They sit in the first chair, play alongside everyone else, tune the orchestra before the first note, and lead from inside the section. That's the posture: in the room with the builder, not a gate at the end.
The slow part moved
AI made building fast. Teams now build their own apps for data entry, workflow and intelligence, often with an agent writing most of the code. The slow part is no longer the build. It's the back and forth after it: the wrong table, the wrong look, nobody sure the app gets used.
The usual answer is another reviewer, another gate, another report. That arrives too late and in the wrong voice: a red X on a finished pull request. Concertmaster works at the other end, before and during the build.
From idea to production, faster
When building took weeks, the slow part was writing the code. With AI agents it takes hours, and the slow part is everything after: finding out the app read the wrong table, sending it back, finding out it's off brand, sending it back again. Each round costs days, because the only person who can spot the problem is the one who knows where the data lives.
Concertmaster takes those rounds out by moving the answers to the front.
Right the first time, not the fourth
The builder gets the house rules before the first line of code, so the first version uses the right data and the right look. Rework you never start is the fastest kind.
Answers in seconds, not a meeting
An agent asks where a record lives and gets the answer mid-task, instead of waiting for the one person who knows. That knowledge stops living in one head.
Prototypes are never blocked
Guidance is advice while you explore. A team turns on a hard stop only for production, if it wants one.
Acceptance reads, it doesn't retest
Reviewers read what the app was allowed to use beside what it actually used, instead of testing round after round to find out.
The next app is the right app
Usage counts show which apps people actually use, so the next idea is chosen on evidence before anyone builds it.
We judge it by friction removed: fewer acceptance rounds and a faster road to production, not the number of problems it finds.
Are your current apps telling the truth?
Concertmaster started with a passing thought. Tom pointed an AI agent at a suite of production apps and asked one simple question: are these pulling the right data? It came back with red flags all over.
Most teams have never asked. Apps that passed review months ago keep running, and nobody checks what they actually read and write. So Concertmaster works on the apps you already have, too. It studies each repo and turns every finding into a question for a person, with the file and line as evidence. Then the database's own audit log shows what each app really did, beside what it was allowed to do. Reading code says what an app might do. The audit log says what it did.
Every finding names its fix and who can act on it, and anything not yet checked says so rather than showing green. New builds get the rules up front. Existing apps get the truth, and a way to fix it.
How it leads a new build
A new app starts on the rules
A new app begins as a repo that already holds its house rules, the house stylesheet, a sample screen and usage recording. The first commit is already right.
The score, before the first line
The house rules are written into the instruction files an AI agent reads before it starts: what this app owns, what it may read, what it must never write, the house look, and the usage to record.
Ask the concertmaster, mid-build
An agent can ask while it works. Where does customer live? May this app write orders? What's the right way to create a person? It can check its own change before committing.
Every rule comes with the how
A rule that can only say "wrong" isn't finished. Each one carries its reason and the specific way to do it in this app.
The house look, for free
The house stylesheet is pinned into every app. Business people building their own apps get the look without thinking about it.
The house rules it hands every builder
Three things are true about every app from its first commit: the right data, the right look, and real use. These are the rules behind them, as the builder receives them.
- One home per record
- Where each kind of record lives and which app owns it. Only the owner writes, unless a write is granted.
- No shadow tables
- Use the record's home. Don't make a quiet copy of it.
- Identity through the hub
- The one right way to create a person or an organisation.
- Validation at the door
- Let the database enforce keys, so bad data stops on the way in.
- No secrets in git
- Keys and passwords stay out of the code.
- Apps sign in as themselves
- The app gets its own login, never a person's.
- Pinned AI models
- Name the exact model, never a "latest" that can change underneath you.
- House style
- The house stylesheet and components, already in place.
- Usage recorded
- Five house events to record: app opened, screen viewed, action taken, query run, export made. It counts how apps are used, never who.
- Signed plan
- A plain-words plan of what the app is and what it won't do, signed by one named person before production. No approval chain.
The choices that make it work
- It can't see your code or your data
- Concertmaster never reaches into a client's repos or systems. Each repo checks itself and sends up only findings: counts, table names, file paths and line numbers. Code, data and secrets stay with you.
- One rulebook, many readers
- The agent's instructions, the answers, the checks and the screens all come from one rulebook, so the guidance and the check can never disagree. The rulebook lives in your git and changes only by reviewed pull request.
- Advise by default
- Building is guided, never blocked. A hard stop exists only where a team turns it on.
What it isn't
Not a PMO or process governance
No approval chains, task chasing or sign-off workflows. It governs apps against the data they use, not people.
Not a data platform or catalog
It holds no business data and replaces no database. It says where data lives and helps apps respect it.
Not people analytics
It counts how apps are used, never who.
Not a design tool
It hands builders the house style you already have. There is no style editor.
Building apps with AI agents, and losing weeks to acceptance rounds?
Talk to us. We'll show you Concertmaster leading a build, and what the same discipline would look like for your builders. Or start with the simpler question: are your current apps telling the truth?
Start a conversation →