Own Vertical Software: what a vertical body is and why it isn't a rebadged SaaS

An industrial electrical installation company in Zaragoza. 140 people, four branches, a mix of public and private contracts. Its managing director has spent two years stuck between two bad options. The first is a fairly well-known construction management SaaS: they trialled it for six months, the way their site managers actually work didn't fit its workflow, and they ended up running half the process in a parallel Excel file. The second is a fully bespoke build. He has had three quotes, all starting above €90,000, all with a twelve-month timeline and none with any guarantee that the result will look like what his people need on day one.

He wants neither. He wants a third option that almost nobody is offering him under a clear name: Own Vertical Software built on a sector body that is already solved. In other words, a system that arrives on day one knowing what a site report is, how invoicing by progress certificate works, how retentions are tracked, how a materials batch is closed and how a subcontractor cycle runs. On top of that, he configures what is his. And if a process is truly unique, he commissions exclusive development, but only for that piece, not the whole system.

That system exists. It's called SVP, Own Vertical Software. The core asset that makes it possible is the vertical body. This article explains exactly what a vertical body is, what it contains, what gets configured per client, what gets developed exclusively and who owns each piece.

It isn't a rebadged SaaS. Nor is it a bespoke build in disguise. It's a different category.

What a vertical body is and why it isn't a template

A vertical body is the set of architecture and data model decisions already solved for a sector. Each company's real operation is then adapted on top of it. That's all.

It isn't a template. A template is an empty screen you copy and fill in. A vertical body brings the sector's entities, the relationships between them, the states of each case file, the validation rules, the characteristic calculations and the traceability the sector demands. When you land on it, you aren't filling gaps. You're inheriting fifty or a hundred technical decisions that someone already made for you after getting inside twenty companies in the same sector.

It isn't a vertical SaaS either. A vertical SaaS is a closed product: the company adapts to it, the vendor decides what goes on the roadmap, and when your workflow leaves the standard track you end up inventing parallel spreadsheets or paying for integrations. The vertical body, by contrast, is the base on which your own system is built. It is extensively configured per client and allows exclusive development when it's genuinely needed.

In plain terms: SaaS asks you to change how you operate. Bespoke development asks you to pay for everything, including what the sector has already solved. SVP with a vertical body asks you to pay only for what is yours and reuse what is already solved.

The practical difference is huge. A typical construction management vertical SaaS imposes its own model of "unit", "chapter", "progress certificate" and "daily report", with the fields the vendor chose. Say your company distinguishes between a direct labour report, a subcontractor report and a heavy haulage report, each with its own approval rules. You either change how you operate to fit the SaaS model or you build yourself a parallel spreadsheet. With a vertical body, those three report variants already exist as configurable case file types, and the approval rule is configured, not programmed.

This is where a lot of managing directors get muddled. They confuse "vertical" with "closed". Vertical doesn't mean closed. It means the depth of the model belongs to a specific sector. Whether the system is closed or open is a separate architecture decision.

The cross-cutting technical framework: the components every SVP repeats

Underneath the vertical body sits a technical framework that repeats in any serious business software, whatever the sector. A vertical body rests on this framework; it doesn't replace it. When someone sells you "bespoke software" and quotes you twelve months, what they're charging you for is programming this framework again from scratch for your company. In a well-designed SVP, it comes already solved.

There are between twelve and fourteen components, and they vary little between sectors:

• Authentication and identity management. Login with email or SSO, password recovery, two-factor where it applies, logout, invitations. Without this there is no system.
• Granular roles and permissions. "Admin" and "user" aren't enough. An operations director sees the whole branch, a site manager only their own, an administrator can read but not approve. The permissions system has to support the company's real map.
• Multi-tenancy and multi-organisation. If tomorrow you acquire a company or open a subsidiary, the system separates data by tenant without duplicating code or servers.
• Data model and ORM layer. How entities are stored, how they relate and how they're queried. It's the skeleton everything else rests on.
• File and attachment management. Uploading a PDF, a DWG, a site photo. Reliable storage, preview, versioning, file size control. It sounds basic and it's where most SaaS products fall over.
• Configurable approval workflows. A case file goes through N steps, each step is approved by a role, it can be sent back, it can be escalated. A generic engine, not one hard-wired to a specific process.
• Notifications and traceability. Who did what and when. Outgoing email, in-app notifications, audit log. Without this you can't defend yourself in an inspection or in a dispute with a client.
• Search and filtering over long lists. Finding one case file among 40,000. Filtering by status, date, owner, client. Sorting. Exporting. People underestimate this until the system holds three years of data.
• KPI dashboard and reporting. The operation's numbers in real time, not monthly reports built by hand. KPIs configurable by role.
• Integrations and API. Output to accounting, input from the ERP, connectors for electronic signature, for the email gateway and for the Sede Electrónica (the Spanish public administration's online portal) when needed.
• Internationalisation and multi-language. Even if you only operate in Spain, having it in the base saves you paying to redo everything if you open in Portugal tomorrow.
• Observability and logs. When something fails in production, knowing why in five minutes, not five days.
• Backups and recovery. Daily backup, retention, restore testing. Not optional.
• Admin panel for the system itself. Adding users, enabling modules, changing parameters without asking for a deployment.

That framework is 60% of the real cost of any serious business development. When the €90,000 quote for a conventional bespoke build lands, more than half of it goes here. And there is nothing specific to your sector in it. There is only engineering that has already been done thousands of times.

Rule: if your vendor doesn't show you this list before talking about anything else, they're going to charge you for rebuilding it.

What a sector vertical body contains

On top of the technical framework sits the vertical body. This is where the system stops being generic and starts understanding the sector.

A sector vertical body contains at least four layers:

1. Sector data model. The sector's own entities and their relationships. In electrical installations: Project, Progress certificate, Work report, Materials report, Subcontractor, Retention, Developer client, Contractor client, Branch, Crew. In law firms: Case file, Matter, Procedural step, Client, Opposing party, Procedural deadline, Funds on account. In private medical centres: Patient, Clinical record, Episode, Prescription, Appointment, Informed consent, Practitioner, Medical panel. The vendor doesn't improvise these entities on day one. They come from the sector and are already validated.

2. Case file types and life cycles. Every sector has processes with defined states. A construction case file goes through Awarded, In progress, Suspended, Provisionally accepted, Finally accepted, Settled. A clinical case file goes through Open, Under review, Closed, Archived. These cycles, with the valid transitions between states, the alerts on change and the permissions per state, are part of the vertical body. Nobody programs them again.

3. Sector business rules. Calculating the monthly progress certificate cumulatively to date, including materials on site, deducting advance payments and applying the retention. Calculating the deductible funds on account. Calculating margin per project net of subcontracting. Checking that an informed consent is signed before a procedure is scheduled. These rules exist because the sector demands them, not because you invent them. They come solved.

4. Documents, templates and regulatory traceability. A legal services vertical body brings the engagement letter template, the case file cover sheet and the funds on account form. A construction vertical body brings the progress certificate in the format the tender specifications require, the setting-out record and the daily report. A clinical vertical body brings informed consent by type of procedure, with a versioned history. They're configured per client, but the base structure comes from the sector.

The vertical body doesn't cover 100% of the sector. It covers the common trunk shared by 80% or 90% of the companies in that sector. Whatever is genuinely different about your company gets configured or developed exclusively, as we'll see now.

Reality check: a serious vertical body takes two or three years of work with companies in the sector to build. You can't improvise one in a month. When someone tells you "we'll have a vertical for your sector in a month", what they'll deliver is a CRUD of empty screens, not a validated sector model.

What gets configured per client and what gets developed exclusively

This is where SVP parts company with both SaaS and bespoke.

In a vertical SaaS, the vendor draws the line between what you can configure and what you can't. You accept what's there or you migrate. In a classic bespoke build, everything can be modified, but everything costs money and time, because there's no reusable trunk.

In an SVP with a vertical body the line is explicit and agreed at the start of the project. There are three clear zones.

Zone 1: Per-client configuration

What gets adjusted without writing a line of code. Someone on the client or vendor side changes it from an admin panel, in minutes or hours.

• Terminology and labels. If your company calls something an "action" where the standard says "activity", it gets changed.
• Custom fields. Adding your own fields to Client, Case file or Document without touching the core.
• Specific approval workflows. Setting who approves what, and in what order, within the workflow engine.
• Permissions by role and by branch. Matching the real organisational map.
• Document templates. Customising the progress certificate, the standard contract and the consent form with the company's logo, legal name and house clauses.
• KPIs and dashboards. Choosing which metrics each role sees, over what time period and with what filters.
• Standard integrations. Enabling and configuring the connectors for accounting, email and electronic signature.
• Alerts and notifications. Which events trigger which message to which person.

All of this is pure configuration. It adds no technical debt risk, doesn't require deep testing and doesn't block future updates to the vertical body.

Zone 2: Configured extension

What gets solved by combining existing pieces of the vertical body with deeper parameters. It takes work, but it doesn't reinvent anything.

• A new case file type derived from a base one, with its own states and rules.
• A new complex approval workflow with conditions by amount, branch or client type.
• A new derived calculation built on parameterisable formulas.
• A new report using data from the standard model.

This isn't programming from scratch. It's using the system's engine to configure a more elaborate case. It takes days, not months.

Zone 3: Exclusive development

What is genuinely yours and doesn't fit in configuration. It gets programmed, tested, documented and deployed. But only that piece, not the whole system.

Real examples of the kind of exclusive development that shows up in SVP projects:

• A sales commission calculation with three tiers on a variable scale, tied to client seniority and contract type, specific to your sales network.
• An integration with a legacy ERP from the nineties that has no standard API.
• An algorithm for assigning crews to work reports based on availability, specialism and geographical distance, with its own rules.
• A very specific operational screen that the warehouse manager uses two hundred times a day, which needs keyboard shortcuts and a very particular yes/no flow.

Exclusive development is the expensive part. But with 80% covered by the vertical body and configuration, that exclusive part is proportionally small. In typical projects it accounts for between 10% and 25% of the total cost, not 100%.

Working rule: if your vendor doesn't draw these three zones in the proposal and doesn't tell you how many hours fall into each, they aren't selling SVP. They're selling smoke and mirrors with a nice label.

Ownership: what stays with the client and what stays with the vendor

This is the part most sales conversations dodge, and it's the most important. A managing director who doesn't settle ownership before signing ends up trapped in a system they can't leave. A CTO who doesn't settle it finds out when they try to migrate.

In a well-designed SVP, ownership is agreed layer by layer.

The vendor's: the cross-cutting technical framework and the sector vertical body. This is their product: the engineering they've built over years of work with several clients in the sector. It makes sense for it to stay theirs. It evolves with every new client that joins, and everyone benefits. A vertical body improves when the vendor gets feedback from twenty companies in the sector and folds the improvements into the common trunk.

The client's: the data, always. Their instance with all its operational information. The exclusive developments they paid for, with a contract that says so in plain words. The technical documentation for those developments. Access to the data via standard export and via API at any time.

Shared, with judgement: the standard configurations and the specific templates the client has designed. Agree that the client can use them freely outside the system in future, and that the vendor can fold anonymised learnings into the vertical body, but never the exact detail.

The three points you need to see written into the contract before signing:

• Data portability. An explicit clause stating that the client can export all their data in a structured format (CSV, JSON or SQL) at any time and at no cost. Without this, the system is a prison.
• Source code and ownership of exclusive development. The code for the exclusive pieces: who can use it, where it's hosted, what happens if the relationship ends. Ideally the client receives the source code for their exclusive pieces, either in escrow or directly.
• Continuity if the vendor disappears. A written contingency plan. How the system is accessed, how the data is migrated, who can maintain the vertical body if the vendor closes.

Critical note: some serious SVP vendors have had this in their contract since the first version. Others leave it vague. A client who doesn't ask for it doesn't get it.

It stings, but it tells you something: if the vendor gets nervous when you ask for these clauses, you have your answer before signing.

How to tell whether your operation fits an SVP with a vertical body

Not every company needs an SVP. Some are fine with a sector SaaS because their workflow fits entirely within the standard. Others need a fully bespoke build because their business model is so particular that no vertical body will do. Most industrial, professional services and private healthcare SMEs with 20 to 200 people sit exactly where an SVP makes sense.

These are the objective criteria that separate a good fit from a poor one.

You fit if...

• You've tried one or two sector SaaS products and your people still work in Excel for at least one critical process. This is the clearest signal. The SaaS covers part of the job and misses the rest, and the team fills the gap with a spreadsheet. That doesn't scale.
• You have between 20 and 200 people. Below that, SaaS is usually enough. Above it, you start looking at your own product or at corporate systems. In between, SVP is the sweet spot.
• Your turnover is between €3 million and €40 million. Enough volume to recoup the cost of an SVP and avoid the trap of accepting a SaaS that constrains your growth.
• Your sector has a clear common trunk of case files, cycles and regulation (construction, private healthcare, legal services, distribution, logistics, accredited training, administrative and tax agencies, technical consultancy). If your sector already has three or four mature vertical bodies on the market, the trunk exists.
• You have at least one technical person in-house who can hold their own with the vendor. You don't need a senior CTO. You do need someone who understands data, processes and systems and can ask for specific things.
• Your workflow has between 3 and 10 clearly differentiating processes compared with the sector average. No fewer (SaaS would do) and no more (you'd need a fully bespoke build).

You don't fit if...

• Your company has fewer than 15 people and turns over less than €2 million. The sunk cost of an SVP won't pay back. You're better off with a SaaS, accepting its rigidity and compensating with targeted automations.
• Your sector is so niche that there's no mature vertical body on the market. You'd either have to build one from scratch (expensive) or wait.
• Your operation changes substantially every six months. An SVP makes sense once the workflow settles. If you're pivoting constantly, any system is obsolete before it has bedded in.
• You don't have a budget of at least €40,000 to €80,000 for the first year across implementation and ongoing development. These are indicative market ranges you can check against agencies such as Vertebra Gestión, Cero Ideas or ASD Solutions, depending on sector. Below that, you'll end up on a SaaS.
• You aren't willing to document how you really work. An SVP is configured on what you actually do, not on what you say you do. If your team can't describe its real flow in four meetings, no system will capture it.

If you ticked four or more from the first list and none from the second, an SVP with your sector's vertical body is probably the best strategic systems decision you can make for the next three years.

Common mistakes when contracting an SVP

Managing directors who come to an SVP with the wrong mindset tend to trip up in the same places. These are the five most common mistakes, each with its symptom and fix.

Mistake 1: Confusing a vertical body with a template. Symptom: the vendor shows you nice screens and tells you "this adapts to whatever you want". They don't show you the data model or the case file cycles. There's no technical documentation for the vertical body. Fix: ask to see the sector's entity-relationship diagram before signing. If there isn't one, there's no vertical body. There's a CRUD.

Mistake 2: Not agreeing the three zones in writing (configuration, extension, exclusive). Symptom: the quote arrives with no breakdown. There's just a single figure and "implementation services". Three months into the project, everything you ask for is "additional development" and the cost shoots up. Fix: require an hourly breakdown for each block in the proposal, with a list of the pieces that fall into each zone. If any of your processes isn't mapped to a zone, don't sign.

Mistake 3: Not settling ownership of the exclusive code. Symptom: you pay €20,000 for a specific development and the contract only says "licence to use". When you want to leave, that code stays with the vendor and you lose the logic of your most distinctive process. Fix: an ownership clause for the exclusive development or, at the very least, code escrow. Both are market standard in serious contracts.

Mistake 4: Putting too much into exclusive development from day one. Symptom: the client insists that "in our case everything is different" and asks for bespoke programming of processes the vertical body's configuration already covers perfectly well. The project turns into a bespoke build in disguise, expensive and slow. Fix: commit to running on vertical body configuration alone for the first ninety days. See where it really hurts. Build exclusive pieces only for what still hurts once the system is up and running.

Mistake 5: Handing the implementation to the vendor and disappearing. Symptom: the managing director signs, passes the project to "someone responsible" who has no authority to decide, and doesn't look at it again until the system goes live. That's when they find out twenty decisions have been made that they don't like. Fix: appoint an executive sponsor with real time committed (at least four hours a week for the first three months) and a schedule of fortnightly steering meetings with minutes.

These five mistakes explain most of the SVP projects that went wrong. None of them is the vendor's. All of them are the client's. Leave them uncorrected and exhaustion is guaranteed.

Frequently asked questions

What exactly is Own Vertical Software and how does it differ from a vertical SaaS?

Own Vertical Software (SVP) is a business system built on a sector vertical body (architecture and data model already solved). It is extensively configured per client and allows exclusive development for the pieces that are genuinely different. A vertical SaaS, by contrast, is a closed product that the vendor evolves on its own roadmap and that the company adapts to. With SVP the system adapts to the company; with SaaS it's the other way round.

Is there anything between a sector SaaS and building software from scratch?

Yes. That's exactly what SVP with a vertical body is. You reuse 60 to 80% of the system (the common technical framework plus the sector vertical body) and only pay for exclusive development on the 20 to 40% that genuinely sets your workflow apart. The result costs much less and takes much less time than a fully bespoke build, with far more flexibility than a SaaS.

How is a business system built from a reusable sector architecture?

The typical process has four phases. Diagnosis of the client's real workflow and mapping against the sector vertical body (two to four weeks). Configuration of the system with the company's own entities, permissions, workflows and templates (four to eight weeks). Exclusive development of the pieces that don't fit in configuration (variable, from four weeks to three months). Go-live by branch or by process, with support and ongoing development.

What does it mean for business software to be "owned" by the company that uses it?

It means three specific, contractual things. One: the data belongs to the client and can be exported at any time at no cost. Two: the exclusive developments the client paid for are theirs, with the code in their possession or in escrow. Three: the instance is configured in detail to the client's real workflow, not the other way round. The sector vertical body remains the vendor's property (it's their product, built up across several clients), but everything specific to the client belongs to the client.

How much does a typical SVP project cost and how long does it take for an SME with 50 to 150 people?

Indicative market ranges for the first year (implementation plus ongoing development), which you can check against reference vendors such as Davisa, Pistacho Digital or Efiprox: between €40,000 and €120,000 depending on sector and the volume of exclusive development, with the system in productive use within three to six months. That's roughly half the cost of a fully bespoke build, and comparable in payback to a sector SaaS once you add up licences, integrations and the hidden hours of parallel work in Excel.

What happens to the system if the SVP vendor disappears?

It depends on the contract. A serious contract includes a continuity plan: permanent access to the data, escrow of the code for the exclusive developments, up-to-date technical documentation of the vertical body in your instance and alternative vendors able to maintain the system if the original one closes. If the contract doesn't cover this, the dependency risk is high. Ask for it before signing, not after.

Closing

The electrical installation company in Zaragoza chose SVP. It signed four months after it started looking at options, with a vertical body for industrial construction management, extensive configuration of its certification and approval workflows, and three pieces of exclusive development: the commission calculation for its site managers, the integration with the ERP it has been carrying since 2011 and the operational screen for the central warehouse. Initial cost within the sector's indicative range, go-live by branch in five months, data and exclusive developments owned by the company under contract.

What it didn't buy: a SaaS that forced it to rebuild how it operates. Nor did it buy a bespoke build charging ninety thousand euros to rewrite login, permissions, attachments and workflows that already exist in any serious business system on the market. It bought the option in between, which has a technical name: Own Vertical Software built on a vertical body.

It isn't magic. The business software industry solved 80% of the work a long time ago, and most SMEs keep paying for it from scratch every time. Reusing what is already solved is a strategic decision, not a shortcut.

If you've ruled out SaaS for its rigidity and bespoke for its cost, the useful conversation is about the detail: which vertical body exists for your sector, which parts of your workflow fall into configuration and which into exclusive development, and what the ownership contract would look like. That gets worked out in a working session. You can start by reading how SVP works at apferrer.com or book a 30-minute session to review your case.

Related reading

• Own Vertical Software - the full proposal
• From the problem to the tool that works - the FDE methodology applied to systems
• Book a diagnostic session - 30 minutes, no cost, no hidden scope