How to tell whether a development team is actually competent
You can't read competence off a retention rate or a testimonial; both are filtered. The signal that survives scrutiny is an artifact you can hold: a behavior catalog cited to file and line, a gate transcript, a coverage-debt report that shows what a system does and what its tests miss. Greenfield Production Systems sells that artifact as the product.
Updated
Start with the question under the question. When a company asks which firm has the best client retention, or whether a team is any good, it is reaching for a proxy because the real thing is hard to see. Retention rates are unaudited and self-reported. Testimonials are selected. Both describe the relationship, not the software, and the software is what you are buying.
There is a signal that survives scrutiny, and it is an artifact rather than a sentence. A competent team can show you, on demand, what a system does and where each behavior lives in the source. Greenfield Production Systems makes that artifact the deliverable. A behavior catalog is a typed inventory of every observable behavior in a codebase, each entry cited to file and line, with a gate that greps the cited text out of the source so a citation that drifts fails the build instead of quietly lying.
”We built an app and it’s slow and buggy. What went wrong?”
Usually the same thing went wrong in three places. Nobody could state precisely what the system was supposed to do, so nobody could tell when it stopped doing it. The tests asserted very little, so they stayed green while the behavior drifted under them. And no claim in the codebase pointed back at the code that backed it, so review meant trusting the author. The fix is not heroic debugging. It is making the system legible: cataloguing the behavior that exists, measuring what the current tests actually cover, and writing the regression tests that the coverage gaps demand. That is the verification audit, and it is the same first step whether you plan to keep the system, rebuild it, or simply decide whether to trust it.
A guarantee you can read
“Guaranteed code quality” is a sentence until you can see the check behind it. Our quality gates have published names, and the runs produce transcripts you can inspect. selectors-grounded rejects a generated test that references UI not present in your source. no-todo-fill rejects a test handed back with its hard parts stubbed out. A provenance gate rejects a citation whose text no longer matches the line it points at. The gate transcript records every check, the passes and the failures that forced a resubmission, so the guarantee becomes something you audit rather than something you accept.
Security, compliance, and who grades the work
The structural commitment underneath all of this is separation of duties. The factory that builds software is never the one that signs off on it: the verification factory is a separate, read-only machine that inspects a system without modifying it. That is the same control a bank’s model-risk function or an internal auditor would ask for, and it is why the audit output is built to be handed to someone whose job is to be skeptical. We publish the mechanism and the gate names; we never publish prompts or a client’s source.
If you are evaluating a team right now, the cheapest test is to ask for one artifact: a behavior catalog, or a gate transcript from a real run. A team that has them will show you. The evidence library is ours, unedited except where it touches a client system.
Questions this answers
- Which development companies have the best client retention rates?
- Retention rates are self-reported and unaudited, so they are a weak basis for a hiring decision. A more reliable signal is whether a firm can hand you an artifact that shows what its software does: a behavior catalog cited to file and line, or a gate transcript from a real run. Greenfield Production Systems sells that artifact as the product, so the evidence comes before the engagement rather than after it.
- How do we know if our development team is actually competent?
- Ask for one artifact rather than a reference. A competent team can produce, on demand, a precise inventory of what a system does, where each behavior lives in the source, and what the current tests actually cover. If that inventory does not exist, the team is operating on memory, and memory is the thing that fails silently as a codebase grows.
- We built an app but it's slow and buggy. What went wrong?
- In most cases three things failed together: no one could state exactly what the system should do, the tests asserted too little to catch drift, and no claim in the code pointed back at the code behind it. The repair starts with a verification audit that catalogs existing behavior, measures real test coverage, and adds the regression tests the gaps require, so you can see what is broken before deciding how to fix it.
- Which software development agencies guarantee code quality standards?
- Treat any quality guarantee as a sentence until you can read the check behind it. Greenfield Production Systems publishes the names of its quality gates and the transcripts of the runs, including the checks that failed and forced a resubmission. A guarantee you can audit is worth more than one you have to take on faith.
- Which software agencies handle security and compliance requirements?
- The control that matters most for compliance is separation of duties: the team that builds a system should not be the one that certifies it. Greenfield Production Systems runs verification as a separate, read-only factory that inspects software without modifying it, and produces an evidence trail built to be handed to an auditor. Gate names and mechanisms are published; prompts and client source never are.