"What you don't separate in the quote, you pay for twice in the operation."
Ingeniería Bética Servicios is a 78-person company based in Seville that subcontracts building services projects for public tenders. Its operations director has spent a year and a half trying to replace the software they use to manage tender documents, bids, contracts and milestone billing. He has sat through four demos. He has received three quotes. All of them landed on similar numbers: between €45,000 and €90,000 for implementation, plus a monthly fee of €800 to €2,400. All of them came with the same line: "this adapts to your operation".
When he asked for a breakdown of which part was standard, which part was configuration and which part was bespoke development, none of them could give a clear answer. One sent him a spreadsheet with generic line items such as "advanced parameterisation" and "process consultancy". Another told him that "everything is included in the implementation". The third, more honestly, said it depended on "whatever comes up".
That is the problem AVA answers.
AVA, Adaptive Vertical Architecture, is a five-phase method that explicitly separates the productised common layer, the configurable differential layer and the exceptional layer that gets developed. The goal is not philosophical. It is accounting. Every line of the quote and every clause of the contract has to show which layer the thing being paid for lives in. Without that separation, implementing vertical software becomes a black box where the supplier bills indistinguishable hours and the client signs without knowing what they are signing.
What AVA is and what each of its five phases guarantees
AVA is applied on top of a vertical body: software that already covers 70-80% of the common processes in a sector (public tenders, road haulage, dental clinics, customs, niche insurers) and adapts to the remaining 20-30% that makes each company unique. Without that base body, there is no AVA. You would be talking about pure bespoke development, and that is a different conversation.
The five phases are sequential. Each has a verifiable output that the client signs off before moving to the next:
- Phase 1. Diagnosis. Output: fit report against the vertical body and classification of every process into the three layers (common, configurable, specific).
- Phase 2. Mapping. Output: catalogue of the organisation's real processes cross-checked against the vertical body, with a signed list of what gets activated, what gets configured and what gets developed.
- Phase 3. Configuration. Output: pre-production environment with rules, permissions, templates and workflows fitted to the operation, plus an internal administration manual.
- Phase 4. Migration and validation. Output: historical data loaded, production environment signed off on real cases worked by the client's team, not by consultants.
- Phase 5. Operation with support and evolution. Output: maintenance contract with a numerical SLA, a quarterly evolution allowance and a versioning policy for the vertical body.
Each phase has an invoice, a deliverable and an acceptance criterion. You don't move to the next one until the previous one is closed.
Rule: if a supplier cannot break their proposal down into these five phases with an amount per phase, they are not selling an adapted vertical body. They are selling hours.
Phase 1: what goes into the diagnosis and why it comes before signing scope
The diagnosis is the only phase that can be contracted on its own, with no commitment to continue. That is deliberate. A vertical body may not fit a company's operation, and the diagnosis is where that shows up before anyone signs a €50,000 contract. The diagnosis costs roughly 5% to 10% of the estimated total budget, according to market ranges published by Vertebra Gestión and Cero Ideas for vertical ERP and CRM implementations.
At Ingeniería Bética the diagnosis took three weeks and produced four concrete deliverables:
- Map of current processes. Not a vague diagram. Each process described in input-output-owner format. At Bética that came to 34 operational processes, of which 11 were documented in the internal manual and 23 lived only in the heads of three people.
- Classification into three layers. Each process is tagged as common (covered by the vertical body untouched), configurable (covered after adjusting parameters and templates) or specific (requires development). At Bética the split was 21 common, 9 configurable, 4 specific.
- Estimate per layer. Common processes carry zero adaptation cost because they are already productised. Configurable ones are estimated in configuration hours at a fixed rate. Specific ones are estimated as development with detailed scope, or marked "out of v1".
- List of risks and blockers. Integrations with legacy systems, data formats that won't migrate cleanly, regulatory approvals that require external validation. Each risk comes with a probability and a mitigation cost.
With those four documents, the operations director has, for the first time, an accounting picture of what he is buying. He can take it to the board, ask for a second opinion, decide not to go ahead. That's the whole point. A diagnosis that only exists to justify closing the sale is not a diagnosis.
The diagnosis exists so the client can say no with all the information on the table.
Critical note: an honest diagnosis sometimes concludes that the vertical body doesn't fit. When that happens, the diagnosis is billed, the report is delivered and another route is recommended (another supplier, another type of solution, development from scratch, staying with what they already have). Turning down a €60,000 project because the fit is 45% is not generosity. It is refusing to poison an operation that would fail within six months.
Phase 2: how the vertical body is mapped against real processes
Mapping is the phase where the vertical body is cross-checked, process by process, against the organisation's real catalogue. It isn't done in a meeting room. It is done at the desk where the work happens, with the person who runs the process, the vertical body's screens open and the current paperwork and spreadsheets to hand.
At Bética the mapping took five weeks. The result was a catalogue of 34 processes with the following final split, adjusted from the initial diagnosis:
- Common processes activated untouched (22). Supplier onboarding, client onboarding, bid cycle, standard contract generation, milestone billing, basic bank reconciliation, document management, deadline tracking, renewal alerts, audit log. All of this already lives in the vertical body. It is switched on with a permission and tested with two real cases. Adaptation cost: zero.
- Configurable processes (8). Here the vertical body's parameters are adjusted to reflect the company's own rules. At Bética: bid approval escalation by amount (three tiers), contract templates with sector-specific staff transfer clauses, the abnormally-low-bid calculation using the formula set by the Junta de Andalucía (the regional government of Andalusia), integration with the public procurement platform to download tender documents automatically, bank guarantee generation with two preferred banks, project close-out with a 5% retention for 12 months, a profitability report per job with two views (commercial and technical), and a tax notification when invoicing to the same client goes over €3,000 in the quarter.
- Specific processes that get developed (4). Calculation of a special bond required by the regional administration under its own ordinance, a site-report system with biometric signature by the site manager that syncs with the standard module, an integration with the legacy accounting software the company doesn't want to replace in v1, and a regulatory report that an institutional client requires in its own XML format.
The deliverable for this phase is a document the operations director signs line by line. Each process carries its layer, estimated effort in hours or days, the person responsible for approving each configuration and the person on the client side who will validate the result.
In plain terms: if someone says "we'll sort that out during implementation" at this stage, the mapping hasn't been done. A PowerPoint has.
Phase 3: what stays in the client's hands when configuration ends
Configuration is the phase where the vertical body becomes the tool Ingeniería Bética will actually use. It is done in a pre-production environment, with fictitious but realistic data, and it produces two things: a working system and an internal administration manual.
The second is the one that matters. Configuration cannot stay solely in the supplier's hands, because then every future change means calling the supplier and paying for it. AVA requires that, at the close of phase 3, the client has:
- Full access to the configuration layer. An admin panel with permissions, templates, approval workflows, rates and calculation rules. All of it editable by an internal administrator with average training.
- An administration manual written for this operation. Not the vertical body's generic documentation. A manual that says: "to change the bid approval escalation, go to Configuration > Workflows > Bid approval and edit the tiers". With screenshots of the real installation, not of the supplier's demo environment.
- Training for two profiles. A functional administrator (typically the head of systems or operations) who can change the configuration. And end users by role (sales, site engineer, admin) trained only in their own part.
- Recorded working sessions. When someone new joins the team in two years' time, there is reference material that doesn't depend on the supplier still existing or still being the same supplier.
At the close of phase 3, Ingeniería Bética can change approval tiers, add contract templates, adjust rates and create new reports without opening a ticket. Structural changes to the vertical body remain the supplier's job. Operational configuration belongs to the client. That is the line.
A client who depends on the supplier to change an approval tier hasn't bought software. They've rented a hostage.
Example: four months after go-live, Bética decided to change the bid approval workflow to add a fourth tier above €200,000 requiring the CEO's signature. The head of operations did it in 40 minutes. No ticket, no invoice, no wait. That autonomy is what gets signed in the phase 3 close-out record.
Phase 4: how data is migrated and why the client's team does the validation
Migration is the most underestimated phase and the one that sinks the most projects. Ingeniería Bética had 11 years of history: 4,200 clients, 890 suppliers, 3,100 jobs, 28,000 invoices, 14,000 documents linked to contracts, a history of site reports in spreadsheets from 2019 onwards and a rate base with 340 items whose prices had changed six times.
AVA breaks migration into three clearly separate blocks:
- Master data. Clients, suppliers, employees, rates, templates. Migrated first, cleaned (duplicates, broken codes, badly formatted phone numbers) and validated against the source system with a differences report. Rule: if the migration leaves more than 2% of records unreconciled, you stop and investigate. At Bética the first attempt left 8% duplicate clients because of variants of the CIF (the Spanish company tax ID) with and without hyphens. Work paused for three days to clean it up before continuing.
- Transactional data. Jobs, bids, contracts, invoices. Migrated with an explicit cut-off date. Everything before the cut-off is loaded as closed, read-only history. Everything after it is worked in the new system from the start. You never migrate "the whole system" without a cut-off, because that guarantees inconsistencies.
- Documents. Contract PDFs, scans of incoming invoices, drawings, certificates. Loaded and linked to the corresponding record. At Bética 14,000 documents were loaded with a script that linked them by job code. The 380 that found no match were listed in a report for manual review.
The supplier doesn't do the validation. The client's operational staff do, working real cases for two or three weeks in parallel with the old system. AVA calls this the shadow phase. Every morning the Bética team entered the same transactions in both systems and compared results at the end of the day.
Differences were logged in a shared sheet. After three weeks, the number of differences had been zero for five consecutive days. That was the cut-over criterion. From the following Monday, the old system went read-only and all new work went through the new one.
Symptom: if only the supplier does the validation, with their own data and in their demo environment, it isn't validation. It's a demo with more screens.
Rule: no system cut-over without five consecutive days of zero differences on real cases worked by the client's team.
Phase 5: how the system runs with support and which evolution policy gets signed
The fifth phase is not an ending. It is the permanent mode in which the system lives alongside the operation. AVA requires the operating contract to have three separate blocks with independent prices: maintenance, evolution and versioning of the vertical body.
- Maintenance. Covers incident support, fixing errors attributable to the supplier, system availability and response to failures. Signed with a numerical SLA: maximum response time by severity (critical, high, medium, low), minimum monthly availability (usually 99.5% for management systems, no more), communication channel (ticket portal with traceability, not email). The cost is roughly 15% to 22% a year of the implementation amount, according to ranges published by Davisa and ASD Solutions for vertical ERP and CRM.
- Evolution. A quarterly allowance of hours for small or medium changes the organisation decides to prioritise: a new report, a workflow tweak, a minor integration. Bought in advance and consumed against a board the client can see. Unused hours roll over for one more quarter. If they run out, you buy another allowance. It is never mixed with maintenance, because maintenance is reactive and evolution is proactive.
- Versioning of the vertical body. The vertical body evolves through periodic updates (new features, regulatory changes, security improvements). The contractual policy defines how often they are applied, who decides, how they are tested in pre-production before going to production and what guarantees exist over the client's configurations and specific developments. The AVA rule: configurations and specific developments must keep working after every new version of the body, or the supplier bears the adaptation cost.
That last point is the one most often left out of contracts. A vertical body that updates and breaks the client's configuration every six months ends up costing more than bespoke development. The backward compatibility clause covering configurations and specific developments is what makes the model sustainable.
Critical note: a supplier who won't sign backward compatibility over configurations and specific developments is telling you, without saying it, that every evolution of their vertical body will generate extra invoices for the client. Read it that way and decide with that information.
How AVA shows up in the quote and in the contract
After the diagnosis, Ingeniería Bética's operations director received an AVA quote that looked nothing like the previous three. It was structured by phase, with cost per layer inside each phase, estimated hours per line item and acceptance criteria per deliverable. An anonymised summary:
- Phase 1. Diagnosis: closed. €4,800. Already invoiced at the start of the process.
- Phase 2. Mapping: €8,400. Five weeks. Deliverable: signed catalogue of 34 processes classified into three layers.
- Phase 3. Configuration: €22,000. Eight weeks. Deliverable: signed-off pre-production environment, written administration manual, training delivered to both profiles.
- Phase 4. Migration and validation: €14,500. Six weeks. Deliverable: system in production with five days of zero differences on real cases.
- Specific developments (4 processes): €18,200. Quoted one by one. Each with detailed scope, acceptance by unit test and a compatibility guarantee with upcoming versions of the body.
- Phase 5. Operation, year 1: annual maintenance fee €8,400. Quarterly evolution allowance of 40 hours at €65 an hour, €2,600 per allowance. Versioning policy documented in an annex.
Added up, that quote was comparable in total to the three earlier proposals. The difference was visibility. Every line item had a name, a deliverable, an acceptance criterion and an owner. There were no lines like "process consultancy" or "advanced parameterisation" soaking up open-ended hours.
The contract followed the same structure. Each phase with its close date, its deliverable and its payment clause. Specific developments in their own annex. Operation with a numerical SLA, a sized allowance and a versioning policy. An external commercial lawyer, hired by Bética to review it, spent three hours reading it and came back with two minor comments. When the contractual structure is clear, the legal review is short.
An AVA quote can be read in twenty minutes. An opaque quote needs six meetings to understand.
Common mistakes when applying AVA
Mistake 1: Skipping the diagnosis to go "faster". Symptom: the supplier proposes starting straight with configuration using a fixed package. Fix: say no. Without a diagnosis there is no separation between layers, and the project slides into indistinguishable hours before the end of the second month.
Mistake 2: Putting specific processes into the configuration phase. Symptom: the phrase "we'll do this with some creative configuration" appears. Fix: if a process needs new logic, it is specific development, with its own scope, its own invoice and its own guarantee. Dressing it up as configuration hides the real cost and shifts into maintenance a risk that belonged in development.
Mistake 3: Accepting migration without a shadow phase. Symptom: the supplier says "we'll migrate over the weekend and go live on Monday". Fix: require two or three weeks of parallel running with daily validation against the old system, and cut over only after five consecutive days of zero differences on real cases.
Mistake 4: Contracting maintenance without a numerical SLA. Symptom: the contract talks about "support during business hours" with no times or severities. Fix: an SLA with severities, maximum times per severity, minimum monthly availability, a channel with traceability and a penalty proportional to the breach. Without numbers, the SLA doesn't exist.
Mistake 5: Signing without a backward compatibility clause over configurations and specific developments. Symptom: the versioning policy says that "updates may require adaptations that will be billed separately". Fix: require backward compatibility to be the supplier's responsibility. If the vertical body evolves and breaks one of the client's configurations, whoever decided to change the body pays to fix it.
Frequently asked questions
What is Adaptive Vertical Architecture
It is a method for adapting vertical software (a body that already covers 70-80% of a sector's common processes) to an organisation's specific operation. It does this by sorting each process into three layers (common, configurable, specific) and running five sequential phases (diagnosis, mapping, configuration, migration and validation, operation with support). The goal is for the quote and the contract to show clearly what is paid for in each layer and in each phase.
How do you adapt vertical software to a specific company's operation
With the five AVA phases. First, a diagnosis classifies each of the company's processes into the three layers and estimates effort per layer. Then the processes are mapped against the vertical body and what gets activated, configured and developed is signed off line by line. In the configuration phase, parameters, templates and workflows are adjusted, and a manual and training are handed over so the client can change the configuration on their own. Next, data is migrated with a cut-off date and validated over three weeks of parallel running. Finally, the system is operated under a maintenance contract, an evolution allowance and a versioning policy.
What phases does implementing Own Vertical Software involve
Five. Diagnosis (fit report and classification into three layers). Mapping (process catalogue signed off line by line). Configuration (pre-production environment, administration manual, training). Migration and validation (data load with a cut-off and a shadow phase until zero differences). Operation with support and evolution (maintenance with an SLA, quarterly evolution allowance, versioning policy with backward compatibility).
How do you separate the common from the specific in a bespoke software project
With the three AVA layers. The common layer is everything the vertical body handles out of the box without changes (typically 60-70% of processes): record creation, standard cycles, document management, audit. The configurable layer is processes that exist in the body but are adjusted with parameters and templates to reflect the company's own rules (typically 20-30%). The specific layer is everything that needs new development because it isn't covered (typically 5-15%). Each layer has a different cost, a different effort and a different guarantee.
How long does a full AVA implementation take
It depends on the size of the organisation and the number of specific processes. In a company of 60-100 people with 30-40 operational processes, the total is usually between 5 and 8 months from signing the diagnosis to closing phase 4. Diagnosis 3-4 weeks, mapping 4-6 weeks, configuration 6-10 weeks, migration and validation 4-8 weeks.
What happens if the diagnosis concludes the vertical body doesn't fit
The diagnosis is billed (5-10% of the estimated budget), the report is delivered with the layer classification and the reasons for the misfit, and another route is recommended. An honest diagnosis that says "this doesn't fit" saves the client €40,000-80,000 on a failed project. Turning down a project that doesn't fit is part of the method.
Closing
AVA is neither a new nor an original methodology. It is the disciplined application of a simple idea: if you separate the common, the configurable and the specific in writing, and run five phases with a signed deliverable in each, implementation stops being a black box and becomes an accountable project. Every line of the quote has a name. Every month you know which phase you're in. Every future change is priced against a signed catalogue, not against someone's memory of a meeting.
For the operations director handling the purchase, this comes down to two concrete things. First: he can take the quote to the board without having to interpret it. Second: when the project moves forward and changes come up (and they will), he can negotiate them against a document that says exactly what was signed and what is out of scope. Without AVA, every change is an open argument. With AVA, every change is an entry in the catalogue with an amount and an acceptance criterion.
If you are weighing up buying vertical software for your operation and you've been handed a quote you can't break down by phase, by layer and by process, ask for a separate diagnosis before signing anything bigger. In the free 30-minute session we review your current quote, pick out which line items are mixing layers and which specific questions you should put to the supplier so the contract reflects what you are actually buying. And if you want to see how AVA is applied to a specific vertical body, the Adaptive Vertical Architecture page has the full operational description of the five phases and their deliverables.
Next articles in the SVP Fundamentals series:
- Vertical body vs bespoke software: why the common 80% changes the economics of the project
- Quarterly evolution allowance: how to size it without giving hours away or falling short
Related reading:
