Process Transparency: How We Scope, QA, Secure, and Deliver Projects

A Clepsydra Technologies perspective on why "how you work" matters more than "how big you are."

Why we're writing this down

Most vendor pitches lead with outcomes — the app you'll get, the dashboard you'll see, the launch date on the calendar. Fewer vendors explain the mechanics underneath those outcomes: how a request becomes a scoped plan, how quality gets checked along the way instead of at the finish line, how security gets treated as a design constraint rather than an afterthought, and how a finished build actually lands in your hands.

We think that mechanical layer is where trust is actually built or lost. An enterprise buyer evaluating a services partner isn't just asking "can they build this?" — they're asking "will I be surprised halfway through?" So this article is our attempt to answer that question honestly, in public, before you ever sign a contract with us.

1. Scoping: the work we do before writing any code

Industry data on why software projects go sideways keeps pointing to the same root cause, and it isn't a lack of engineering talent. Analysis of enterprise IT delivery has found that project requests tend to be vague, under-scoped, or disconnected from business outcomes, and when that foundation is missing, time, morale, and money get quietly drained before the project even begins. In other words: the most expensive mistakes happen on page one, not in the codebase.

Our scoping process is built to close that gap before it opens:

We start with the problem, not the feature list. One of the clearer explanations of good scoping we've come across puts it this way: the best brief for a software project describes the operational problem being solved and the outcomes that would constitute success, not the specific features the system should have. Features are a solution — not the requirement. We push on this early, even when a client arrives with a fully-formed feature list, because the team that understands the underlying problem builds better solutions than the team that just executes a checklist.

We break the project into a real work breakdown, not a single number. A detailed breakdown of modules, dependencies, and milestones is what makes a timeline defensible rather than a guess — it's the same discipline recommended across enterprise software scoping literature, where a detailed work breakdown serves as the baseline to evaluate project success and weigh the eligibility of changes. This is also what protects both sides from scope creep: when a change request comes in mid-project, we can point to exactly what it displaces or adds, instead of arguing about it.

We keep the scope alive, not frozen. Static requirements documents age badly. Best-practice guidance on custom software scoping emphasizes that teams should revalidate the scope often — frequent validation of the scoping document helps detect misinterpretations in a timely manner, thus averting costly rework. We check in against the original scope at every milestone, not just at kickoff and delivery.

We ask you to be honest about constraints, and we're honest back. Good scoping is a two-way obligation. As one enterprise delivery guide puts it, buyers who come prepared with a clear problem statement and involve the people who will use the system every day produce better requirements and higher adoption after launch. We'll tell you early if a timeline, budget, or integration assumption looks unrealistic — not three weeks before launch.

2. QA: quality checked continuously, not inspected at the end

There's a structural reason "we'll test it at the end" fails on modern projects: by the time testing starts, every defect is expensive to fix, because it's already wired into decisions made weeks earlier. The industry term for the alternative is shift-left testing — moving validation earlier into the lifecycle instead of treating it as a final gate.

The mechanics are well documented. Shift-left testing is described as a QA methodology that moves testing earlier in the SDLC, embedding quality checks during requirements analysis, development, and build phases, replacing the older pattern where critical defects get discovered days before go-live, triggering emergency fixes that introduce new bugs and release delays that cost real money.

What this looks like on our projects, concretely:

Testers are involved from requirements, not from a QA handoff. As one shift-left guide frames it: encouraging QA involvement during requirement gathering ensures testability from the start, which reduces ambiguity and prevents downstream defects.
Every commit triggers automated checks. Modern shift-left practice relies on automation running continuously: executing tests automatically upon every code commit provides immediate feedback to developers, prevents bug regressions, and ensures only verified, high-quality code progresses through the delivery pipeline.
We don't stop watching after launch. Shift-left is only half the picture. The complementary discipline — shift-right — means using real-time monitoring tools to track application performance and health in production, with alerts for anomalies so issues feed back into the development cycle. Quality isn't a milestone we hit and walk away from; it's a loop.

This is also, honestly, where a lean team has an advantage: there's no hand-off friction between "the people who wrote it" and "the people who test it." The same people who understand the business logic are watching it in staging.

3. Security: verified against a standard, not assumed

"We take security seriously" is the least useful sentence in any vendor pitch, because it's unfalsifiable. So instead of saying it, we anchor to something checkable: the OWASP Application Security Verification Standard (ASVS) — the open, community-maintained benchmark that most of the industry uses to actually define what "secure" means for a web application.

ASVS matters here for a specific reason: it isn't a vague checklist, it's a basis for testing web application technical security controls, developed to normalize the range and rigor of security verification available in the market. Practically, that means:

It scales to risk, not to budget theater. ASVS is structured in tiers, where Level 1 is a minimum acceptable baseline verified through black-box testing, Level 2 is standard verification for applications handling sensitive business data and is appropriate for most enterprise applications handling personal data, and Level 3 is maximum verification for critical infrastructure, financial, or healthcare systems. We scope the security bar to what your data actually requires — we're not selling you Level 3 rigor for a marketing site, and we're not letting a payments integration get away with Level 1.
It plugs into the pipeline, not just a pre-launch audit. A meaningful share of the standard's controls can be automated. Security engineering analysis estimates that roughly 60 to 70 percent of ASVS requirements can be automated through static analysis, dependency scanning, and configuration review, depending on architecture and coverage. We build that automation into CI so security checks run on every change, not once at the end when it's expensive to fix findings.
It's designed to be part of the SDLC, not bolted onto it. ASVS is explicitly meant to be integrated throughout the SDLC — defining requirements, guiding design and coding decisions, and forming the basis for verification testing — which is exactly why we bring security review into design conversations, not just into a pre-launch scan.

We won't claim a threat model is bulletproof — nobody can honestly claim that. What we can commit to is a documented, checkable standard, applied consistently, with evidence you can look at.

4. Delivery: measured, not just promised

The last mile — how a build actually reaches production and how we know it landed cleanly — is where a lot of vendor relationships quietly break down. Deadlines slip without anyone naming why; releases go out and nobody can say with confidence whether they were risky.

We track our delivery discipline against DORA metrics, the five measures that emerged from the DevOps Research and Assessment program's long-running study of engineering organizations. They give both sides a shared, numeric vocabulary instead of vague reassurance:

Deployment frequency — how often an organization successfully deploys code to production. Frequent, small deployments are safer than rare, large ones — smaller changes are easier to review, test, and roll back.
Lead time for changes — the amount of time it takes for a code change to reach deployment and run successfully in production after being committed to the main branch. This is the number that tells you how fast we can actually respond to a request, not how fast we say we can.
Change failure rate — the percentage of releases that cause a problem in production. High-performing teams don't just move fast; they move fast and keep this number low.
Failed deployment recovery time — how quickly a problem gets fixed once it's found. Elite-performing teams recover in under one hour, while high and medium performers typically recover within a day. This is arguably the most honest metric there is, because it assumes something will eventually go wrong and measures how well a team handles that reality instead of pretending it won't happen.

Practically, this shapes how we deliver:

We favor smaller, frequent releases over big-bang launches — the same logic recommended across DevOps practice, where reducing deployment size by breaking work into smaller batches makes releases faster and more manageable when issues occur.
We give you documented handoffs at each milestone — working demos, not just status updates — so progress is something you can see and click through, not something you're asked to take on faith.
We treat the system we hand off as something you should be able to maintain, not a black box that only we understand. Documentation, deployment runbooks, and clean commit history aren't optional extras; they're part of what "done" means.

Why we're telling you all of this

None of the above requires a 200-person engineering org or a decade-long client roster to be true. It requires discipline, and it requires being willing to show our work instead of asking you to trust a brand name.

We'd rather earn that trust with a process you can actually inspect — a scope document you can push back on, a QA pipeline that catches things before you ever see them, a security standard with a name and a public specification, and delivery metrics that are just numbers, not adjectives.

If you want to see how we'd scope your specific project against this framework, that conversation costs nothing to start.

Sources & further reading

Alithya — Why designing an effective project scoping process starts with intake
ScienceSoft — Best Practices to Define a Software Development Project Scope
Vestra — How-To Guide For Scoping Custom Software
Konverge — How Software Development Projects Get Scoped
Virtuoso QA — Shift-Left Testing: Types, Benefits, and Best Practices
PractiTest — Adopting Shift-Left Testing
Testlio — Shift Left Testing Meaning: What & Why It Helps QA
Netalith — Shift-Left Testing: Best Practices for Faster Software Delivery Cycles
OWASP Foundation — Application Security Verification Standard (ASVS)
Aikido — OWASP ASVS Explained: Web App Security Verification Standard
Unicis — OWASP Application Security Verification Standard (ASVS) — Levels Overview
Codific — OWASP ASVS: A Comprehensive Overview
GitLab — DORA Metrics: Software Delivery Performance Guide
IBM — What Are DORA Metrics?
Waydev — DORA Metrics: Measure & Improve DevOps Performance
DORA.dev — DORA's Software Delivery Performance Metrics

Note: figures and framework descriptions above (OWASP ASVS levels, DORA metric definitions, shift-left practices) are drawn from the publicly available sources listed. Internal delivery numbers referenced in client conversations are Clepsydra's own tracked data, not industry averages.