A Delivery Process Designed to Surface Problems Early
Agile sprints inside a CMMI Level 3 appraised framework, with working software every two weeks, written status reports that name slippage, and documented review gates before anything ships.
How does Anviam run a software project?
Anviam runs projects as agile delivery in two-week sprints inside a CMMI Level 3 appraised process framework. Every engagement begins with discovery producing a written scope, architecture and estimate; build proceeds in sprints with a working staging build and a written status report each week; quality gates cover automated tests on every pull request plus an independent QA pass before release; and handover includes architecture documentation, runbooks and full account access. Code lives in your repository from the first commit.
- Sprint length
- 2 weeks, with a demo each sprint
- Reporting
- Written weekly status including slippage
- Process framework
- CMMI Level 3 appraised
- Quality gates
- CI tests plus independent QA pass
- Code ownership
- Yours from the first commit
- Post-launch
- Support window, retainer optional
Projects Rarely Fail Suddenly. They Fail Quietly, Then Suddenly.
The pattern is consistent. A project slips a little in week three and nobody mentions it because it might be recoverable. It slips again in week five. By week ten the gap is too large to close, and that is when the client finds out. Nothing about that is a technical failure; it is a reporting failure, and it is entirely preventable.
So our process is built around making problems visible while they are still cheap. A working build on staging every sprint, so progress is observable rather than reported. A weekly written status that states what slipped and why. Estimates tracked against actuals in the open. It makes for occasionally uncomfortable reading in month two, which is exactly the point.
From First Conversation to Ongoing Support
Discover & Scope
Workshops mapping goals, users, constraints and integrations into a written scope, architecture and estimate you approve before build.
Design & Architect
UX flows and system architecture reviewed with you, with expensive-to-reverse decisions flagged explicitly at sign-off.
Build in Sprints
Two-week sprints, working software on staging every sprint, weekly written status and a demo you attend.
Test & Launch
CI tests on every pull request, an independent QA pass, performance and security review, then a staged release.
Support & Scale
A defined support window, monitoring, and either a maintenance retainer or a full handover to your team.
The Points Where We Formally Stop and Check
CMMI Level 3 appraisal means these gates are documented and evidenced on every engagement, not just large ones.
Scope Sign-Off
A written scope, integration inventory and estimate that you approve. Nothing gets built against a verbal brief.
Architecture Review
Data model, integration contracts and infrastructure reviewed, with reversible and irreversible decisions distinguished.
Code Review on Every Change
No commit reaches a main branch without review against your standards, not ours.
Independent QA Gate
A QA function separate from the developers who wrote the feature, with a written release recommendation.
Security & Performance Pass
OWASP-aligned review and load testing before release, not after a customer reports something.
Handover Verification
Documentation, runbooks and access confirmed complete, tested by someone rebuilding the environment from them.
What We Put in Writing on Every Engagement
Most dissatisfaction in software delivery comes from expectations nobody wrote down. These are contractual rather than aspirational.
Talk to Our Team- Your repository and cloud accounts from the first commit, with no proprietary framework dependency
- The engineers named in the proposal are the engineers who do the work
- No subcontracting of engineering without your written agreement
- A weekly written status report that states slippage rather than hiding it
- A working build on staging every sprint, so progress is observable
- Maintenance pricing quoted before you commit to the build
Three Commercial Shapes, Chosen to Fit the Work
The model matters as much as the process. Picking the wrong one creates friction no amount of good delivery fixes.
Fixed Scope
A defined feature set, price and date. Right when requirements are genuinely stable and budget certainty matters most.
Dedicated Team
A standing pod billed monthly, reprioritised every sprint without change orders. Right for evolving product roadmaps.
Staff Augmentation
Individual engineers embedded in your team. Right when you have your own technical leadership and need capacity.
Paid Discovery
A short engagement producing scope, architecture and estimate, yours to keep with no obligation to continue.
Assessment Only
An audit or review delivered as a standalone written deliverable, vendor-neutral by design.
Maintenance Retainer
Security patching, dependency updates, monitoring and incident response against agreed response times.
Common Questions About How We Work
Agile delivery in two-week sprints, inside a CMMI Level 3 appraised process framework. In practice that means sprint planning, a demo of working software at the end of every sprint, a written status report including anything that slipped, and documented review gates at architecture, pre-launch and handover. The CMMI part supplies the review discipline; the agile part supplies the ability to change direction between sprints without a change order.
Re-prioritising the backlog between sprints costs nothing and is expected. What does cost is reversing a decision baked into the data model or an integration contract, so we identify those decisions explicitly at architecture sign-off and mark which ones are expensive to unwind. On fixed-scope contracts, changes are handled through a written variation; on dedicated-team engagements you simply reprioritise.
What shipped, what is in progress, what is blocked and by whom, hours consumed against the estimate, risks we have newly identified, and anything that slipped with the reason. Slippage is stated rather than absorbed quietly until a deadline, because a schedule problem reported in week three is a manageable decision and the same problem reported in week ten is not.
You do, from the first commit. Repositories are in your GitHub or GitLab organisation, deployments run in your cloud accounts, and third-party services are registered under your organisation. We avoid proprietary frameworks entirely, so another team can take over without us. Handover includes architecture documentation, runbooks, environment setup instructions and credentials for everything we set up.
Automated tests run on every pull request, with a merge gate on the critical suite. Before a release, an independent QA pass covers functional and regression testing on a device and browser matrix drawn from your analytics, plus performance checks and a security review. For public-facing work we also run an SEO and accessibility pass, and compare a full crawl against the redirect map when URLs have changed.
Every launch includes a support window with agreed response times for defect triage and fixes. Beyond that you can take a maintenance retainer covering security patching, dependency updates, uptime monitoring, backup verification and a monthly report, or take it fully in-house using the handover pack. Both are normal outcomes and the retainer is quoted before you commit to the build rather than afterwards.