Question 1

What is Volt X Foundry, and what exactly do I receive?

Accepted Answer

Foundry is an eight-week structured development contract that takes a founder from a defined idea to a live, production-grade platform running on their own domain. It is a full custom build, not a template configuration and not a prototype. Your platform ships as four connected systems The main application, where you and your providers, suppliers, and internal teams run the business day to day. The database and access management layer, which keeps every user, role, partner, and record isolated and auditable. The storefront and marketing site, which turns visitors into billed, paying customers through native Stripe integration. The content management and observability layer, so your team can publish copy without a developer and see how the product behaves in production. You also receive formal security, performance, and accessibility reports in week seven, and the complete source repository at handover.

Question 2

What is the total price, and what does it cover?

Accepted Answer

The total contract value is £49,670, structured in two parts: £9,830 paid by you across three milestone fees during the build, and £39,840 recovered from qualifying transaction revenue after you are live. The three milestone fees are £2,850 at kick-off, £3,440 at the week five sandbox review, and £3,540 at launch. The remaining £39,840, roughly 80% of the build cost, is carried by Volt X and recovered only if your platform earns. There is no separate retainer, no hosting invoice during the recovery period, and no hourly billing on top.

Question 3

Why is this £49,670 when an AI tool can build an MVP for a few hundred pounds?

Accepted Answer

Because you are not buying the same thing. A prompt-built MVP produces something that demonstrates well on your machine along the one path you tested. It establishes nothing about what happens when a real customer, a real payment, a genuine attack, or the ten-thousandth record arrives. The measured gap is not a matter of opinion. Across more than 100 language models and 80 security-sensitive tasks, 45% of AI-generated samples introduced an OWASP Top 10 vulnerability, with an 86% failure rate against cross-site scripting. Duplicated code blocks are at their highest recorded level while refactoring has collapsed from 21% of changes to 3.8%. Those defects are invisible at launch and surface at the point someone decides whether to trust you with their data. The honest comparison is not £500 against £49,670. It is £500 plus your own months of unpaid time, plus the rewrite that falls due exactly when you finally have users and revenue, against a system engineered correctly the first time. Founders routinely spend more than this program costs establishing that the inexpensive version does not hold. There is also the cash-flow point. You are not asked for £49,670. You are asked for £9,830, and the rest is contingent on your platform actually earning.

Question 4

How does this compare with hiring an agency or building an in-house team?

Accepted Answer

A development agency quoting this scope will typically ask for the full amount in staged payments regardless of outcome, and the timeline is measured in months rather than weeks. An in-house team means recruiting a senior engineer or technical co-founder before you have a product to recruit them onto. The structural difference here is where the risk sits. An agency is paid whether or not the product earns. Under this contract, £39,840 of the cost is recovered only from transaction revenue, so we carry the downside with you. That also means we screen applications on commercial viability, because our recovery depends on it.

Question 5

Why only one founder a month?

Accepted Answer

Two reasons, and neither is artificial scarcity. Delivering an audited, production-grade platform in eight weeks requires concentrated senior engineering attention, and that capacity is finite. More importantly, every accepted project puts £39,840 of our own capital at risk. We cannot underwrite an unlimited number of builds, so each application is assessed on market viability and go-to-market readiness before we commit.

Question 6

What is the catch? Why would you carry £39,840 of risk?

Accepted Answer

Because Blaze makes it economically rational for us. Our platform compiles applications from validated contracts rather than assembling them by hand, so the cost of producing an enterprise-grade build is materially lower for us than the market rate we would otherwise quote. We can therefore price against your future revenue instead of your current bank balance. The trade-off is selectivity. We only accept projects where we believe the platform will transact, because that is how we are paid. There is no equity component, no ongoing royalty beyond the £39,840 cap, and no obligation to keep using us after handover.

Question 7

What do I actually pay, and when?

Accepted Answer

Three payments across the eight weeks, £9,830 in total, each against an invoice issued under the signed agreement. Week 1, £2,850 due at kick-off, when the techno-commercial contract is signed and scope is documented. Week 3 front end walkthrough: nothing due. Week 5, £3,440 due at the sandbox review, once you have seen the functioning build against the agreed acceptance criteria. Week 7 testing and reports: nothing due. Week 8, £3,540 due at launch, once your product is deployed on your domain. The remaining £39,840 is never invoiced as a cash demand on your business. It is recovered only through the agreed share of qualifying transaction revenue.

Question 8

How does the £39,840 recovery actually work?

Accepted Answer

Your business owns and operates the Stripe account. Under a Stripe Connect arrangement that you authorise, each qualifying transaction is split: 80% settles to your account and 20% is transferred toward the recovery balance. The arrangement is capped. Once settled transfers have been reconciled against £39,840, the recovery allocation is switched off permanently and 100% of your transaction revenue continues to you. In plain arithmetic, a 20% share means recovery completes after approximately £199,200 of qualifying transaction volume through the platform. If you never reach that, recovery simply never completes.

Question 9

What counts as a qualifying transaction?

Accepted Answer

The signed agreement defines this precisely rather than leaving it to interpretation. It sets out which payment flows are in scope, the calculation basis, and how VAT, refunds, disputes, chargebacks, processor fees, and taxes are treated before the recovery share is computed. This is one of the terms we encourage you to read closely and negotiate at kick-off. A vague definition of qualifying revenue is exactly the kind of ambiguity that damages a working relationship later, so we would rather settle it in writing before the build starts.

Question 10

What happens if my product never makes money?

Accepted Answer

If the platform generates no qualifying transaction revenue, no recovery payment arises through this mechanism. The £39,840 is not converted into a cash debt, an invoice, or a personal guarantee if your business does not transact. Your total exposure in that scenario is the £9,830 you paid across the eight weeks, and you still own a fully built, audited platform. That is the risk we take on deliberately, and it is why we screen for commercial viability before accepting a project.

Question 11

How long does recovery normally take?

Accepted Answer

It depends entirely on your transaction volume, and we will not pretend otherwise. At a 20% share, the cap is reached after roughly £199,200 of qualifying volume. A platform processing £25,000 a month reaches that in about eight months; one processing £8,000 a month takes closer to two years. There is no time limit that converts the balance into a cash demand, and no interest accrues on it. Recovery ends when the cap is reconciled, whenever that happens.

Question 12

Can Volt X access or control my Stripe account?

Accepted Answer

No. Your business owns and operates the Stripe account. Volt X has no login, no administrative access, and no ability to move funds, and we never hold your customers' money at any point. The recovery share is a pre-agreed Connect transfer configured with your authorisation, applying only to qualifying transactions and only up to the cap. Stripe processes the payments and remains subject to its own terms with you. Your business stays responsible for its products, customers, refunds, disputes, taxes, and compliance obligations.

Question 13

What happens to refunds, chargebacks, and disputes?

Accepted Answer

The agreement sets out how each of these is handled before the recovery share is calculated, so you are not transferring a share of revenue you subsequently had to return to a customer. Because your business is the merchant of record, you retain the commercial relationship with your customers and remain responsible for resolving their refunds and disputes under your own terms and Stripe's.

Question 14

How is VAT and invoicing handled on the recovery amounts?

Accepted Answer

Volt X issues the invoices and accounting records required by law for amounts transferred, including VAT where applicable, so your bookkeeping has proper documentation for every transfer. Those documents record the recovery transfers that have already occurred. They do not create a separate cash-payment obligation on top of the agreed recovery mechanism.

Question 15

What happens when the £39,840 cap is reached?

Accepted Answer

The recovery allocation is disabled and 100% of your transaction revenue continues to your business. Nothing further is owed under the build contract. Reconciliation of the cap also triggers the planned handover: full repository and server ownership transfer to you, and we migrate the platform to your infrastructure under the agreed migration plan.

Question 16

Can I settle the balance early in cash instead?

Accepted Answer

Yes. Founders who raise a round or reach profitability sometimes prefer to clear the balance and take ownership sooner. The contract provides for early settlement of the outstanding recovery amount, after which the split is switched off and handover proceeds. The settlement figure is the remaining unreconciled portion of the £39,840. There is no early-settlement penalty and no interest to unwind.

Question 17

What if I want to change payment processor, or route payments outside the platform?

Accepted Answer

The contract addresses this directly, because the recovery mechanism only functions if platform transactions actually flow through the agreed arrangement. Deliberately routing platform revenue around it to avoid recovery is a breach, and the agreement sets out the consequences, including the balance becoming payable. Legitimate commercial changes are a different matter. If your business genuinely needs to change processor, the contract provides for the arrangement to be reconfigured by agreement rather than treating the change as a default.

Question 18

What if I sell the company or raise funding before recovery completes?

Accepted Answer

The outstanding recovery balance is a disclosed contractual obligation of the business, so it appears in diligence like any other supplier arrangement. In practice, acquirers and investors tend to prefer it settled at completion, and the early-settlement provision exists for exactly that. Because the amount is capped, uncollateralised, and free of interest, it is a considerably simpler item on a cap table conversation than convertible debt or an equity grant would be.

Question 19

Does Volt X take equity in my company?

Accepted Answer

No. There is no equity, no share option, no board seat, and no convertible instrument. The commercial relationship is a capped recovery of build cost against transaction revenue, and it terminates at £39,840.

Question 20

Is eight weeks realistic, or is it a marketing number?

Accepted Answer

It is realistic because the schedule is compressed, not the engineering standard. Blaze compiles the architecture, schema, permissions model, and interface from validated contracts rather than assembling them by hand, which removes the majority of the elapsed time in a conventional build. The parts that cannot be compressed are still there: requirement definition, your review at each gate, security and performance testing, and production-readiness checks. The eight weeks includes all of them, with the test reports published in week seven before launch rather than after.

Question 21

What happens in each of the eight weeks?

Accepted Answer

Five gates across eight weeks Week 1, kick-off and techno-commercial contract: vision, modules, features, acceptance criteria, and first-release scope are documented and signed, and account access is confirmed. Week 3, front end design and experience: you review the complete interface, screens, and interaction flows. The backend is not connected yet, so this demonstrates the intended experience using representative content. Week 5, sandbox review: database, authentication, and business logic are connected in pre-production. You review a functioning build against the agreed acceptance criteria. Week 7, stress testing and reports: scoped security, performance, and accessibility assessments are completed and the reports issued to you. Week 8, launch: after production-readiness checks, your product goes live on your domain.

Question 22

How much of my time will this take, and what do you need from me?

Accepted Answer

Your heaviest week is week one, where we work through the product vision, modules, features, and acceptance criteria in detail. Expect to give that several focused sessions, because everything downstream is compiled from it. After that, your obligations are the three review gates in weeks three, five, and seven, plus timely responses on decisions and access. We also need domain control, and access to the accounts the build depends on, confirmed at kick-off.

Question 23

What happens if I am slow to give feedback or provide access?

Accepted Answer

The contract names customer dependencies explicitly, and delays caused by them are one of the few permitted reasons for the launch date to move. This is deliberate on both sides: it protects your deadline from being quietly reinterpreted, and it protects us from carrying a date we cannot control. In practice we flag a dependency in writing as soon as it becomes blocking, so there is a record and no surprise at week eight.

Question 24

Can I change the scope mid-build?

Accepted Answer

Yes, through the change control process in the contract. Small refinements within the agreed architecture are usually absorbed. Material additions are quoted and scheduled, and if they affect the launch date that is agreed in writing before the work starts. Because schema, permissions, API, and interface are deterministically linked in Blaze, structural changes propagate through the system together rather than requiring a manual sweep of the codebase. That makes change materially cheaper here than in a hand-assembled build.

Question 25

What if you miss the week eight launch date?

Accepted Answer

The decision becomes yours. You may cancel the contract and claim a 100% refund of the £2,850 deposit, or agree a revised date with us and continue. The contract fixes the start date, the acceptance criteria for each milestone, and the customer dependencies and approved change requests that are the only permitted reasons for the date to move. Neither side can reinterpret the deadline after the fact.

Question 26

What if the build is not what I expected at the week 3 or week 5 review?

Accepted Answer

That is precisely what the gates are for. Week three shows you the complete interface and interaction design before any backend work is committed, which is the cheapest possible point to correct a misunderstanding. Week five shows you the functioning build against the acceptance criteria you signed in week one. Work that does not meet the agreed acceptance criteria is corrected at our cost. Work that meets the criteria but represents a change of mind goes through change control.

Question 27

What is explicitly out of scope?

Accepted Answer

The build covers the software. It does not include your marketing, advertising spend, content production beyond the structures to publish it, customer support operations, or third-party subscription costs such as your Stripe fees, domain, or paid API usage. Native mobile applications, bespoke machine learning models, and integrations with systems that lack a documented API are assessed case by case and are not assumed to be in the eight-week scope unless the contract says so.

Question 28

What is the technology stack?

Accepted Answer

Every application is built on a standardised, custom-coded stack: Next.js and React on the front end, custom CSS, Node.js services, Supabase PostgreSQL for data, native Stripe for billing, a headless CMS (Sanity or Payload), and Sentry and PostHog for error logging and product analytics. These are mainstream, well-documented, open-standard technologies with large hiring pools. That is a deliberate choice: it is what makes the codebase maintainable by any competent engineer you appoint later.

Question 29

Is my application genuinely custom code, or a template with my logo on it?

Accepted Answer

It is custom code, generated against your own application definition: your modules, entities, fields, relationships, workflows, roles, and business rules. Two Foundry builds for different businesses do not share a data model or a feature set. What is standardised is the architecture, not the product. Every build uses the same proven structural patterns for security, data access, and scale, which is exactly why the published performance and security benchmarks apply to your application rather than to a demo we ran once.

Question 30

Is this a no-code or low-code platform?

Accepted Answer

No. There is no proprietary runtime, no visual builder your team has to learn, and no platform your application must keep running inside. The output is a conventional Next.js and Node.js repository that you own. Blaze is a compilation system we use to produce that repository. It is not something your product depends on afterwards.

Question 31

How many users can the platform handle?

Accepted Answer

A single production container sustains a user base equivalent to 14,000 daily active users and 100,000 monthly active users, holding a 99.98% request success rate at 87.86ms median API latency and a 782ms desktop page load. These come from an independently load-tested audit of the reference architecture. Because Blaze compiles every application to that same architecture, the figures apply to your build rather than to a best-case sample.

Question 32

What happens when I outgrow a single container?

Accepted Answer

Growth is horizontal rather than a rewrite. Three cloned containers carry 42,000 DAU and 300,000 MAU. Seven containers behind a transaction-mode connection pooler carry 100,000 DAU and 700,000 MAU, without refactoring a single line of your application code. Under extreme surge testing the architecture sheds excess load in a controlled queue rather than corrupting data or crashing the database. The scaling path is a configuration change, not an engineering project.

Question 33

Do I get the source code?

Accepted Answer

Yes. You receive the complete repository at handover: readable Next.js and Node.js with no proprietary runtime and no obfuscation. Full repository and server ownership transfer to you on contract completion. The code is written to be handed over. That is a design constraint throughout the build, not a courtesy at the end.

Question 34

Can another engineer or agency take the codebase over later?

Accepted Answer

Yes, and this is one of the clearest differences from a prompt-built codebase. You receive conventional, human-readable code on mainstream frameworks, with a coherent architecture that an engineer can articulate after reading it. There is no dependency on Volt X to keep operating your product, and no proprietary layer a successor team would have to reverse-engineer before they could make a change.

Question 35

Can you integrate with my existing systems and third-party APIs?

Accepted Answer

Generally yes, where the target system exposes a documented API. Common integrations such as payments, email, analytics, authentication providers, and CMS are part of the standard architecture. Integrations with undocumented, legacy, or heavily rate-limited systems are assessed during technical screening and scoped explicitly in the contract, because they carry schedule risk we will not quietly absorb into an eight-week window.

Question 36

Can you build a native mobile app?

Accepted Answer

The standard build is a fully responsive web application that works properly on mobile browsers, with screen transitions capped below 50KB so it stays usable on mobile and restricted corporate networks. Native iOS and Android applications are not part of the standard eight-week scope. If you need them, raise it during screening and we will scope it as a separate engagement rather than compressing it into the eight-week window.

Question 37

Can you rebuild or modernise a product I already have?

Accepted Answer

Frequently, yes, and founders arriving with a vibe-coded prototype that has stalled are a common case. An existing product is often an advantage, because your requirements and user behaviour are already evidenced rather than assumed. Data migration from the old system is scoped during screening. What we will not do is graft new work onto an unsound existing codebase and describe the result as enterprise-grade.

Question 38

Can the product include AI features for my users?

Accepted Answer

Yes. AI capabilities in your product, such as assistants, classification, summarisation, or search, can be scoped into the build like any other feature, with the associated API costs sitting with your business. This is separate from how your product is built. Using AI as a feature is a product decision; using it to improvise your architecture is the failure mode this program exists to avoid.

Question 39

Where is the application hosted, during recovery and afterwards?

Accepted Answer

During the recovery period your product runs on Volt X infrastructure under the agreed service and data-processing terms, with no separate hosting invoice to you. It runs on your domain from launch. At handover we migrate it to your infrastructure under the agreed migration plan. Because every environment is containerised from standard blueprints with a recovery time objective under four hours, you receive a clean, decoupled application shell ready for your own private cloud rather than something welded to our host.

Question 40

Can my team edit content, and will I be able to see how the product is performing?

Accepted Answer

Yes to both. A headless CMS lets your team publish marketing pages, product copy, and blog content without waiting on developers, and the storefront is built for search visibility rather than bolted on afterwards. Sentry and PostHog are configured from day one, so from launch you can see how users behave and where the system fails, rather than discovering both from a customer complaint.

Question 41

What is Blaze, and how much of my product is AI-generated?

Accepted Answer

Blaze is our proprietary platform for producing enterprise applications. AI performs a narrow and supervised role inside it: bounded, low-risk work such as naming, copy, and content within a structure the platform has already compiled and validated. Your data model, access control, security boundaries, and system architecture are produced mechanically by the engine, not predicted by a model. The model does not determine your architecture; it populates defined slots within it.

Question 42

If you use AI, how is this different from vibe coding?

Accepted Answer

The difference is deterministic contracts rather than prompts. Each stage of the build produces a validated artifact the next stage must satisfy: entity and relationship graph, then schema, then role and permission matrix, then interface. A stage that fails its contract does not proceed. Three consequences that a prompt-driven build cannot offer Schema, API, permissions, and interface are a single coupled graph. Rename a field and the database, access rules, and every screen update together, so there are no silent hand-off gaps. Row Level Security, server-side bounded queries, three-tier isolation, and audit-ready structure are compiled in by default and cannot be dropped to meet a deadline, because no individual decides whether to include them. Our engineers review and sign off at every gate, so accountability sits with people rather than with a model.

Question 43

Why can I not do this myself with Claude, Lovable, Bolt, or Cursor?

Accepted Answer

You can produce something that looks like your product. What these tools cannot give you is a guarantee about what they did not do: the tenant isolation they omitted, the permission check they left in the browser, the injection vector they did not consider. Among more than 49,000 developers surveyed across 177 countries, 66% named AI output that is almost right, but not quite, as their principal difficulty, and 45% said debugging it takes longer than expected. If experienced engineers struggle to catch these defects, a founder without an engineering background reviewing generated code is not in a position to. The tools are genuinely useful in the hands of someone who can audit the output. The risk is not the tool. It is using it without that capability on a system that will hold customer data and take payments.

Question 44

What specifically goes wrong with a vibe-coded MVP?

Accepted Answer

The failures are consistent, and each one is invisible at launch and expensive at the point it surfaces. Security improvised screen by screen, with no threat model, so weaknesses are found by your first serious customer or by someone less benign. A schema without referential integrity or row-level security, where the first change to a core entity is a rewrite rather than a migration. Roles hardcoded into the front end and permission checks running in the browser, which is a hidden menu item rather than an access control system. The same logic duplicated across many files, so every change means finding all of them and each one missed becomes a production defect. No audit trail, documented controls, or meaningful test coverage, so the contract that would establish your company stalls at a security questionnaire. The rewrite then arrives at the worst possible moment: when you finally have users, revenue, and no time. You pay for the product twice, and the second time costs more than building it correctly would have.

Question 45

Can I have the code independently audited before I trust it?

Accepted Answer

Yes, and we would encourage it. The codebase is conventional, documented, and free of proprietary runtime, so any competent engineer or security firm you appoint can review it without special access or explanation from us. You also receive our own scoped security, performance, and accessibility reports in week seven, which set out the test basis, findings, limitations, and remediation status.

Question 46

How is security handled?

Accepted Answer

Security controls are compiled in from week one rather than added before launch. That means role-based access control, Supabase Row Level Security, and a three-tier architecture that isolates the data layer from the browser. Data routing bans raw dumps to the browser, so bounded queries process information server-side and there is no exposed customer data for a prospect's security reviewer to find. Multi-factor authentication and OAuth cover your internal teams, providers, and customers.

Question 47

Will the platform be GDPR compliant?

Accepted Answer

We build the technical controls that UK GDPR compliance depends on: access control, data isolation, audit-ready structure, server-side processing, and no unnecessary exposure of personal data to the client. Compliance itself is an organisational responsibility, not a feature we can install. Your business is the data controller for your customers' personal data. The contract includes the data-processing terms governing our role while we host the platform, and your own policies, lawful basis, retention decisions, and any DPIA remain yours to determine.

Question 48

Who at Volt X can see my data and my customers' data?

Accepted Answer

Access is limited to the engineers who need it to deliver and operate the platform, under the confidentiality and data-processing terms in the contract, and only while we host it during the recovery period. After migration to your infrastructure, we hold no access at all unless you separately engage us for ongoing support.

Question 49

Do I get a penetration test or a formal security report?

Accepted Answer

You receive scoped security, performance, and accessibility assessments in week seven, with reports covering the test basis, findings, limitations, and remediation status. We are precise about what these are. They are point-in-time technical assessments that support due diligence. They are not regulatory certification and they do not guarantee future performance. If you need a full independent penetration test from a third-party firm, that can be arranged alongside the build.

Question 50

Will this pass an enterprise security review or SOC 2 audit?

Accepted Answer

The architecture is built to give you the technical controls those reviews look for: Row Level Security, an isolated data access tier, three-tier separation, clean integration with enterprise IAM providers, and code that passes vulnerability scanners without exceptions. SOC 2 and ISO 27001 are organisational certifications awarded to your company after an audit of your processes, not to a codebase. What we can say is that the platform will not be the reason you fail. Because the codebase is predictable and documented, preparation for an external audit is a matter of weeks rather than the months of remediation a patched MVP requires.

Question 51

Where is my data stored, and can I choose the region?

Accepted Answer

Data is held in managed PostgreSQL infrastructure in a region agreed at kick-off, subject to provider availability. If you have a residency requirement driven by your customers or your sector, raise it during screening so it is fixed in the contract rather than discovered late.

Question 52

Is the product accessible?

Accepted Answer

Accessibility is assessed formally in week seven alongside security and performance, and you receive the report. Building to recognised accessibility practice from the outset is considerably cheaper than retrofitting it once you have a public product and an enterprise customer asking about it.

Question 53

Who owns the intellectual property?

Accepted Answer

You own your business data, your content, and your brand throughout. The application built for you, including the source code, transfers to you on contract completion, alongside repository and server ownership. Completion means the launch instalment has been paid. Until then Volt X holds title to the application it has built, which is what makes the deferred structure possible. If that instalment is never paid, ownership does not pass, and the consequences are set out under non-payment at launch below. Blaze itself, the platform we use to produce the application, remains Volt X property. That distinction matters and we state it plainly: you own your product, not the factory that made it. Nothing about the product you own depends on continued access to that factory.

Question 54

What happens if I do not pay the launch instalment after the product is built?

Accepted Answer

The £3,540 falls due at launch, once your product is deployed and working on your domain. By that point eight weeks of engineering have been delivered, so the contract treats non-payment as a serious default rather than a change of mind. The sequence is fixed and you will not be surprised by it. A 30 day grace period If the instalment is not paid on the due date, we issue written notice and a grace period of 30 days. Nothing is forfeited during that window. Pay within it, whatever the reason for the delay, and the contract completes normally: ownership of the application and its source code transfers to you and cost recovery continues as agreed. Statutory interest on late commercial payments may be applied to the overdue amount, and we may suspend the live service while it remains unpaid. If the grace period expires The £2,850 kick-off deposit is forfeited. It is a true deposit and is not refundable in this scenario. The £3,440 sandbox review fee, already invoiced and paid against work you accepted in week five, is not refunded. Ownership of the application does not transfer. Volt X retains the source code, the design work, and the engineering artefacts it produced, which it has held throughout the build and which pass to you only on completion. Volt X may then recover its costs from that work, including by licensing or commercialising the platform it built, whether directly or with another operator. The contract terminates and the revenue recovery arrangement ends with it. What remains yours regardless Your pre-existing property is never in scope and is never transferred or sold. That means your company name, brand, trade marks, domain, and any content or materials you supplied. It also means your business and customer data, which is removed rather than passed on, because we are a processor of that data and have no lawful basis to transfer it to a third party. In practice this position exists to protect a structure in which Volt X has already absorbed £39,840 of build cost before recovery begins. It is a remedy of last resort, and if you are heading into genuine difficulty the sensible step is to tell us before the due date rather than after it.

Question 55

What is the techno-commercial contract, and when do I see it?

Accepted Answer

It is the single governing document for the engagement, signed at kick-off in week one. It covers delivery obligations and dates, acceptance criteria, fees and invoicing, the recovery mechanism and cap, data protection, confidentiality, intellectual property, hosting, refunds, termination rights, and handover. You see it before you pay anything, and we expect you to take legal advice on it. Everything on this page is a plain-language summary. Where the two differ, the contract governs.

Question 56

What are my cancellation and refund rights?

Accepted Answer

Two defined cancellation rights If we do not take your product live by the end of week eight in line with the contract, you may cancel and claim a 100% refund of the £2,850 deposit, or agree a revised date and continue. If a reported fault after launch cannot be resolved within the reasonable period set out in the contract, you may cancel and claim a 100% refund of every milestone fee paid to that point: £2,850 at kick-off, £3,440 at the sandbox review, and £3,540 at launch, £9,830 in aggregate. Cancellation for other reasons, including a change of commercial direction on your side, is governed by the termination provisions in the contract and is not automatically refundable.

Question 57

What support do I get after launch, and what does it cost?

Accepted Answer

Your week seven reports become the standard your live product is held to. If the deployed application does not perform in line with them, we investigate and remediate promptly at no additional charge. Core infrastructure targets 99.9% availability, and while the recovery arrangement is running our commercial interest in your uptime is direct: we are paid from your transactions. New features and ongoing development after handover are optional and quoted as a separate engagement. There is no obligation to retain us, and no penalty for appointing someone else.

Question 58

Will you sign an NDA before I share my idea?

Accepted Answer

Yes. We will sign a mutual NDA before detailed technical discussions, and confidentiality obligations are also written into the main contract. We do not build competing products against our own clients, and we do not reuse your product logic, data model, or content on another build.

Question 59

Who actually builds it? Do you use offshore subcontractors?

Accepted Answer

The build is delivered by the Volt X engineering team on our own platform. Named engineers review and sign off at every gate, and accountability for the delivery sits with us under the contract regardless of how the work is resourced. Any use of subcontractors is subject to the same confidentiality and data-protection obligations we owe you, and the contract sets that out.

Question 60

What happens if Volt X ceases trading before handover?

Accepted Answer

This is a fair question to ask of any supplier hosting your production system, and it is addressed in the contract rather than left to chance. Continuity provisions cover your access to the repository and the infrastructure so that your platform can be operated independently of us. The architecture is designed to make that practical rather than theoretical: standard frameworks, containerised environments from documented blueprints, and a recovery time objective under four hours. If you require a formal source code escrow arrangement, raise it during screening and it can be included.

Question 61

What if we end up in a dispute?

Accepted Answer

The contract sets out the governing law, jurisdiction, and the escalation process to be followed before formal proceedings. Most disagreements in practice are about scope, which is why acceptance criteria are documented and signed in week one rather than described loosely.

Question 62

Who is this program for?

Accepted Answer

Founders with a defined SaaS, marketplace, or store concept that will transact through the platform, who are capitalised for the £9,830 in staged payments, and who have a credible route to customers after launch. It suits people who intend to sell to businesses, handle other people's data, or take payments at volume, which is where the difference between engineered software and a prototype stops being academic.

Question 63

Who is this not for?

Accepted Answer

It is not for founders who regard a vibe-coded MVP as equivalent to engineered software and are optimising purely for the lowest possible upfront cost. If a few hundred pounds of tokens genuinely meets your need, take that route. It is also a poor fit for undefined ideas still looking for a problem, for businesses with no transactional revenue model, and for anyone unwilling to commit review time during the eight weeks.

Question 64

Do you accept deep tech concepts such as biotech, hardware, or novel AI models?

Accepted Answer

Not through Foundry. This is a boundary of the program rather than a statement about our engineering capability: Volt X builds systems of considerable complexity and scale under conventional engagements, and we are glad to discuss those separately. The following are outside the Foundry program specifically: Frontier or foundation model research, and training novel models from scratch Biotechnology, pharmaceuticals, medical devices, and clinical diagnostics Novel hardware, robotics, semiconductors, and materials science Quantum computing and original cryptographic research Autonomous vehicles and safety-critical control systems Businesses requiring a licence we cannot obtain inside the delivery window, such as deposit-taking, lending as principal, or insurance underwriting The reason is structural. Foundry is an eight-week build that recovers most of its cost from transaction revenue after launch. Categories that depend on research timelines, laboratory or clinical validation, hardware iteration, or regulatory approval cannot reach revenue on that schedule, so the commercial model would not be honest for either side. Applied AI is a different matter and is very much in scope. Building a product on established model APIs, with the domain logic, data handling, and accountability around it, is a software problem and we deliver it routinely. Training your own frontier model is not.

Specialist role	Benchmark day rate	Days	Cost
Senior frontend engineerNext.js, React, design system build	£550	35	£19,250
Senior backend and data architectPostgreSQL, RLS, multi-tenant routing, auth	£625	24	£15,000
DevOps and integrations engineerCI/CD, Stripe Connect, CMS, observability	£600	12	£7,200
Product designerFigma system, screens, interaction flows	£475	14	£6,650
QA and test engineerFunctional, accessibility, regression cycles	£375	12	£4,500
Delivery leadSDLC governance, review gates, acceptance	£550	10	£5,500
Cloud, CI/CD, analytics and CMS licencesEnvironments and tooling across the engagement	Direct cost		£1,900
Total build cost	107 specialist days		£60,000

	Traditional agency route	Volt X Foundry
Total build value	£60,000	£49,670
Cash you deploy before launch	£60,000, the full amount	£9,830 across three milestones
Time from signature to live	6 to 8 months	8 weeks
Build cost carried by your partner	£0	£39,840, underwritten by Volt X
Your exposure if the product earns nothing	£60,000, entirely yours	£9,830, and the balance is never owed
Is your partner paid if you do not succeed?	Yes, in full at handover	No, recovery only follows live revenue

Launch your platform idea with an enterprise-grade engineering solution. We put £39,840 of our own capital behind your business.

Volt X will deliver full technical solution in top-tier enterprise quality

Main Application - The Operations Engine

Database & Access Management

Storefront/Landing Page - The Commercial Engine

Content Management & System Logging

We will build your service that meets enterprise-grade performance specifications

Audit-ready application code, not a prototype you have to replace

SOC 2 aligned

UK GDPR compatible

ISO 27001 aligned

HIPAA ready

NCSC Secure-by-Design

PCI-DSS structured

DORA scaled

A good-enough agency working with AI forward, formal SDLC processes will quote you ~£60,000 to match our enterprise-grade engineering specifications

Founder needs to deploy this capital upfront in cash, before launch.Which leaves the founder carrying 100% of the risk

We tie our payment to your success and carry the majority of the risk

This program is not suited to founders who regard a vibe-coded MVP as equivalent to engineered software

What a vibe-coded MVP actually commits you to

How Blaze delivers the same product to an engineering standard

Why founders turn to vibe coding, and why that trade-off is no longer necessary

How your build progresses from kick-off to launch in eight weeks

Kick-off and Techno-Commercial Contract

Front End Design and Experience

The Sandbox Review

Stress Testing and Reports

The Launch

After the Launch

Configured cost recovery through Stripe Connect

What protects your money at every stage

Miss the launch and you can cancel for a 100% refund

Post-launch shortfalls are corrected at our cost

Unresolved faults let you cancel and reclaim your payments

Recovery never gives us control of your money

The Program and the Price

01.What is Volt X Foundry, and what exactly do I receive?

02.What is the total price, and what does it cover?

03.Why is this £49,670 when an AI tool can build an MVP for a few hundred pounds?

04.How does this compare with hiring an agency or building an in-house team?

05.Why only one founder a month?

06.What is the catch? Why would you carry £39,840 of risk?

Payments, Cost Recovery, and Stripe

01.What do I actually pay, and when?

02.How does the £39,840 recovery actually work?

03.What counts as a qualifying transaction?

04.What happens if my product never makes money?

05.How long does recovery normally take?

06.Can Volt X access or control my Stripe account?

07.What happens to refunds, chargebacks, and disputes?

08.How is VAT and invoicing handled on the recovery amounts?

09.What happens when the £39,840 cap is reached?

10.Can I settle the balance early in cash instead?

11.What if I want to change payment processor, or route payments outside the platform?

12.What if I sell the company or raise funding before recovery completes?

13.Does Volt X take equity in my company?

Delivery, Timeline, and Scope

01.Is eight weeks realistic, or is it a marketing number?

02.What happens in each of the eight weeks?

03.How much of my time will this take, and what do you need from me?

04.What happens if I am slow to give feedback or provide access?

05.Can I change the scope mid-build?

06.What if you miss the week eight launch date?

07.What if the build is not what I expected at the week 3 or week 5 review?

08.What is explicitly out of scope?

Technology, Architecture, and Scale

01.What is the technology stack?

02.Is my application genuinely custom code, or a template with my logo on it?

03.Is this a no-code or low-code platform?

04.How many users can the platform handle?

05.What happens when I outgrow a single container?

06.Do I get the source code?

07.Can another engineer or agency take the codebase over later?

08.Can you integrate with my existing systems and third-party APIs?

09.Can you build a native mobile app?

10.Can you rebuild or modernise a product I already have?

11.Can the product include AI features for my users?

12.Where is the application hosted, during recovery and afterwards?

13.Can my team edit content, and will I be able to see how the product is performing?

Blaze, AI, and Vibe Coding