Project Scoping Questionnaire
Questions to define scope, architecture and an accurate build estimate
How this works. The questions below are chosen for one reason only: each answer changes either what I build or what it costs. There are no technical questions — for every one, I've noted why I'm asking and what the answer affects, so you can see the reasoning rather than take it on trust.
Most questions are multiple choice; pick the closest option and add notes where useful. If you're unsure about anything, mark it "to confirm" — I'll record the assumption I've made on that point in the estimate, so you can see exactly what the price is based on. The questions marked Required are the exception: they set the price directly, so the form won't send until they're answered. Either way, these answers determine the scope and the price but don't commit you to anything.
Estimated time to complete: 10–15 minutes.
Where is the company incorporated?
This is the single largest cost driver in the project. Jurisdiction determines which compliance features are mandatory: depth of identity checks (KYC), geo-blocking of restricted countries, in-product risk disclosures, and restrictions on who may hold or transfer the token. A launch into the EU and a launch into a single friendly jurisdiction are materially different builds — potentially very different in cost.
Is the physical gold already held with a licensed third-party vault or custodian? Required
I'm asking about existing arrangements — not advising on them.
Token supply is public on-chain whether we plan for it or not, so the real question isn't whether we can prove reserves — it's how vault data gets connected to something a user can check. A named custodian means there's a counterparty and a report format to integrate against. If custody is still being arranged, we build the connection against a placeholder and wire it up later: same architecture, deferred link — not a smaller build. What usually swings the effort more than this answer is the report source itself, which is what A2b asks.
How would users verify that the gold exists? Required
There's no wrong answer here — it decides how much of that layer we build.
However the gold is held, users need some way to be confident it's really there — and how you prove it is most of the work in this layer. An automated feed from the custodian is an integration with a specific source. A report your team uploads is a different system. An occasional auditor statement with no dashboard is barely any engineering at all. Those three are genuinely different builds, which is why the cost of this layer lives here rather than in whether a custodian exists yet.
Has your legal counsel advised whether the token counts as a security or investment product? Required
The answer decides which features are mandatory rather than optional: approved-transfers-only mode, required risk disclosures, restricted-jurisdiction handling, and audit trails regulators can inspect. It also tells me whether legal sign-off sits on the critical path before launch — which affects the schedule, and therefore the fee if workstreams need to run in parallel.
I am not your lawyer and this isn't legal advice. I only need to know whether one is in the loop, so the build is designed around their requirements rather than discovered after the fact.
Rough figures are completely fine — I only need the order of magnitude.
Who are the users?
Drives identity-verification tiering, interface complexity, support tooling, and whether a native mobile app is needed versus a responsive web app. Retail audiences typically need a considerably larger front-end and more self-service tooling than a smaller verified group, which is a significant difference in build hours.
Roughly how many active users in the first year?
Sets infrastructure sizing and load-testing scope, influences chain choice (cost per transaction compounds at scale), and determines what monitoring and support tooling I need to build or subscribe to. The difference between 500 users and 100,000 is roughly an order of magnitude in hosting and observability cost — not something I want to guess at.
Which countries will users come from at launch?
Drives geo-fencing of the platform, interface localisation, and which payment methods are even available in those markets. Cross-references A1 — the gap between where the company is based and where users are is usually where compliance work hides.
This is where the biggest scope decisions live — the answers here move the estimate more than any other section.
Will users only buy and sell with your company — or can they also send gold tokens to each other? Required
The single largest fork in the whole architecture. Direct-only means a comparatively simple system that mints when users buy and burns when they sell, with tight control and a smaller audit surface. Peer-to-peer transfers require compliance controls that must exist from day one — an approved-transfers list, the ability to freeze or block an account, transfer screening, and reporting — plus noticeably more contract work, more testing and more security audit effort.
This answer alone can change the quote by a wide margin, and it's very difficult to add later without reworking the token design.
Will users be able to move their tokens into their own wallets, or trade them on public exchanges?
Keeping tokens inside the platform is by far the simpler build: users never see a private key, and recovery is just a password reset. Letting users withdraw means I design for self-custody — key management, recovery, and a very different security posture — because if someone loses their keys, the gold is gone and support cannot help them.
Public trading additionally means external liquidity work (such as a trading pool), listing coordination, and the compliance surface that comes with it. This is also the one case where an intermediate stablecoin genuinely earns its place.
When a user cashes out, is it money only — or can they claim physical gold? Required
Physical delivery adds an entire operations module: bar inventory and allocation, minimum order quantities (typically one full bar), shipping, insurance, claims and disputes handling, and the paperwork that goes with them. Cash-only redemption is comparatively simple — the system burns the tokens and triggers a payout.
This question on its own can move the estimate by 30% or more, so it's worth settling deliberately rather than discovering it mid-build.
Does the company plan to pay users any return beyond the gold price itself? Required
Any return mechanism is a separate financial product sitting on top of the gold token, with its own risk, its own regulatory weight and its own set of calculations. It's a meaningful addition to scope. I'd normally recommend keeping it out of version one — but I need to know if it's on the roadmap so the architecture doesn't have to be rebuilt to accommodate it later.
How will users pay in?
Select all that apply at launch.
Every payment method is a separate integration with its own provider, its own onboarding, and its own compliance handling. Launching with one rail and adding others later is usually far cheaper than building all of them up front.
This is also the direct answer to whether users need to buy an intermediate token first: if they can pay by card or bank transfer, they don't. The intermediate step is only genuinely useful if your audience is already crypto-native or you want round-the-clock settlement.
Which of these would you like available at launch?
Tick everything you'd want — I can phase the rest.
Each item here is cheap to decide now and expensive to discover halfway through the build. A tick-list lets me capture the long tail of scope without turning the questionnaire into twenty pages. Anything you tick becomes a line item in the estimate — anything you don't, I can quote separately as a later phase.
How does the company earn revenue?
Select all that apply.
Determines the complexity of the pricing engine and the reporting you'll need. A simple fixed spread is straightforward; tiered fees, per-user fee schedules or subscriptions each add calculation and reporting logic, and each needs to be verifiable by your finance team. This also tells me how much of the admin panel is about money.
How are payouts delivered when users cash out?
Select all that apply.
Each payout route is an integration with a payment provider plus the compliance checks attached to sending money out — identity, sanctions screening, limits. Outbound payments carry more regulatory weight than inbound, so I need to know how many routes exist before I can price the payments work.
Do you have existing systems this needs to work with?
Select all that apply.
Integration work is the most commonly missed line in a first estimate. "We already use X" is comparatively quick — the connection points are known. "We have nothing, choose for us" means evaluation, setup and negotiation before any code is written. Both are fine; they just cost differently.
Who needs to be able to independently see what's on the network? Required
You're commissioning your own chain, so this isn't about picking an existing one — it's about who can independently check what it says.
Since you're building your own chain, this is a business decision as much as a technical one — who may look determines what you're able to promise your users. If you're the only operator, an explorer you publish proves very little: you would be the sole source of the data people are reading, so "verification" reduces to trusting your report. Adding the vault operator or an auditor as a second party gives genuine independent checking without running anything publicly, and that is usually the best value of the three.
Opening the network to the public is the strongest claim you can make, but it means operating an open network and securing it permanently, which is the most expensive option to run.
Worth knowing now rather than later: moving from a closed network to an open one is not a switch you flip. It means rebuilding the part of the system that decides who is entitled to agree on what the network says — cheap to allow for during design, expensive to migrate after launch.
Do you have brand and interface design assets, or is design part of this project?
Separates "build the system" from "design and build the system". Interface design is its own workstream with its own timeline and its own cost — and it's much easier to price when I know whether I'm working within existing guidelines or creating them.
The internal tools your team uses are often the largest part of the build — worth being specific here.
What will your internal team need to do in an admin system?
Select all that apply.
The admin panel is very often half of the total build, and it's the part clients most frequently under-scope — because it's natural to picture the app users see and not the tooling needed to operate it. Every capability above is a real screen, with real permissions, real audit logging and real testing.
Being specific here is the most effective way to keep the final invoice close to the quoted figure.
Do users need downloadable statements or tax / accounting reports?
Reporting is cheap to specify in week one and disproportionately expensive to bolt on at the end, because it needs data the system wasn't originally recording. Asking now means I capture the right history from day one even if the reports themselves are built later.
Who checks identity documents — an automated provider, or your own staff?
Automated checking is primarily an integration with an established provider. Manual checking means I build a review queue — document viewing, approval and rejection flows, notes, history, permissions. It's a different system with a different cost, and it tends to grow once staff start using it.
Is there a target launch date — and is there a fixed deadline behind it?
Determines how many workstreams run in parallel and therefore how large the team needs to be — which affects the fee directly. A date with slack is cheaper than the same scope on a fixed date. It also flags whether legal approvals sit on the critical path, since that can delay launch independently of the development work.
Is an independent security audit of the contracts and the network itself required?
For a product that holds people's money, this should be yes. It's a separate line item — an external security firm, their own fee, and a lead time measured in weeks rather than days — so it needs scheduling from day one rather than discovered at launch.
My recommendation: budget for it. A defect in a contract holding real assets is not a bug you patch on Monday.
After launch — who will run and maintain the network?
Changes the engagement from a one-off build to a build-plus-retainer, and determines how much documentation, runbooks and training are in scope before I finish. It covers the software and the network itself: somebody has to keep the nodes running, apply upgrades and respond when they go down — permanently. It also affects design choices — a system handed to an in-house team should be built for their stack and habits, not mine.
If there's a constraint, commitment or requirement I should know about — an investor expectation, an existing supplier, a regulatory conversation in progress — this is the place for it.