Engagement models
How VenSoc is bought, and what actually drives the number.
There is no rate card on this page. A published day rate is an anchor argued down before anyone understands the scope, and it prices twenty-three years of architectural judgement against a marketplace average. What follows is how each model works and what moves the price, so the first conversation can be about scope rather than discovery.
In short
- 01
Discovery & technical assessment
Best for: Deciding whether to build at all, and what it would really take.
One to two weeks, fixed price, fixed deliverable. VenSoc reads the existing system, interviews the people who operate it, and returns a written assessment: current-state architecture, the constraints that are actually binding, a costed delivery plan in phases, and the risks visible from where we are standing.
What it looks like
- Fixed price agreed before work starts
- A written document, yours to keep and to share
- No obligation to continue with VenSoc
- Credited against the first delivery phase if you do
Commercials
Quoted as a single fixed fee after a free ninety-minute technical review. The review itself costs nothing and is not a sales call with a deck.
Not right when
You already know exactly what you want built and have the technical specification to prove it. Go straight to fixed-scope delivery.
- 02
Fixed-scope delivery
Best for: A defined outcome: an integration, a migration, a replacement for a process that runs on spreadsheets.
A specified system delivered against agreed acceptance criteria, in fortnightly increments you can deploy. Scope, acceptance criteria and the verification gates are written down before the first commit, which is what makes a fixed price honest rather than a bet.
What it looks like
- Scope and acceptance criteria agreed in writing first
- Deployable increments every two weeks, not a single delivery
- Change requests priced individually, never absorbed silently
- Code and IP yours from the first commit
Commercials
Priced per phase against the plan produced in discovery. Where discovery has not happened, the first phase is discovery.
Not right when
The requirements are genuinely still moving. Fixed scope against unstable requirements produces either a padded price or an argument, and usually both. Take retained capacity instead.
- 03
Retained capacity
Best for: Continuous product development where the roadmap is real but the next quarter is not fully specified.
An agreed monthly capacity, directed by you against a rolling backlog. You get the same engineer continuously rather than whoever is on the bench, and priorities can change between increments without a commercial renegotiation.
What it looks like
- Agreed monthly capacity, invoiced monthly
- Priorities set by you at the start of each increment
- The same named engineer throughout
- Thirty days notice either way, no exit penalty
Commercials
Monthly, quoted against committed capacity. Longer commitments reduce the rate; none of them lock you in beyond the notice period.
Not right when
You need a hard delivery date for a hard commercial deadline. Capacity is not a guarantee of scope — take fixed scope for the deadline and retained capacity for everything around it.
- 04
Support & operations
Best for: A system already in production that someone has to own.
Monitoring, incident response, dependency and security patching, and a named engineer who is accountable when it breaks. Applies to systems VenSoc built and to systems it inherited, though an inherited system starts with a paid assessment.
What it looks like
- A named on-call owner, not a shared inbox
- Agreed response targets written into the contract
- Dependency and security patching as standing work
- Runbooks for the failures we anticipated, updated after the ones we did not
Commercials
Monthly retainer scaled to the system’s size and the response targets you need. Inherited systems are assessed first — quoting support for a system nobody has read is guesswork.
Not right when
You want a fixed monthly fee that also absorbs new feature work. It never holds; the features get squeezed or the support does.
What actually drives the number
Feature count is rarely the expensive part. These four are, in roughly this order.
- 01
Integration surface
The number of systems that must agree, and whether their contracts are documented. An SAP OData interface with a published $metadata schema is a known quantity. An undocumented interface owned by a vendor who is slow to answer email is not, and that difference is worth more than the feature list.
- 02
Data quality and history
Migrating ten years of production data with inconsistent historical rules routinely costs more than the application that reads it. This is the single most under-estimated line in enterprise projects, including by people who have been burned by it before.
- 03
Required assurance level
A system where a wrong record is an inconvenience and one where a wrong record is a regulatory event need different amounts of test, audit trail and review. Both are legitimate; they are not the same price.
- 04
Decision latency on your side
The cost driver clients control most directly and estimate least. An engagement where a question is answered in a day moves at a different speed to one where it waits for a fortnightly steering committee.
Common questions
- Why is there no day rate on this page?
- Because a published rate becomes the anchor before anyone understands the scope, and it prices architectural judgement against a marketplace average. VenSoc quotes per engagement after a technical review. The review is free and produces a written assessment you keep either way.
- Can you work to a fixed price?
- Yes, where the scope and acceptance criteria are written down first. A fixed price against unwritten requirements is either padded or a bet, and both end badly. Where requirements are genuinely still moving, retained capacity is the honest model.
- Who owns the code?
- You do, from the first commit, under every model. Ownership of the code, the infrastructure definitions and the documentation transfers to you as it is written, not on final payment.
- What does it cost to leave?
- Nothing beyond the notice period. Exit provisions and knowledge transfer are written into every contract from the start, and no part of a delivered system depends on VenSoc-hosted infrastructure unless you asked for it.
A number is only useful once someone has read your system.
The technical review costs nothing and produces a written assessment. If we are not the right firm for the work, that is what the assessment will say.