Ask for a data model and an API sketch for each part of the product before you ask for a number. A good answer comes back as tables, endpoints and a named owner per domain. If what arrives is a slide deck, you have learned how the build will be run.
Why ask about the data model before the price?
A quote is a number attached to a scope. If the scope lives in a deck, the number is a guess about something nobody has written down yet.
The data model is where scope first turns into decisions. Whether an order belongs to a user or to an account is a data model decision. So is whether one customer can sit in two tenants.
These choices are cheap to make in week one and expensive to change after launch. A partner who can talk about them before a contract is signed has usually made them before.
As a CTO you know this already. What helps is having the questions ready for the first call.
What should you ask a software partner before price comes up?
Five questions cover most of it. The table sets each one next to what a good answer and a weak answer sound like.
| Ask | Good answer | Weak answer |
|---|---|---|
| 'Which tables does each part of the product own?' | A list per domain. Payments owns invoices, refunds and ledger entries. Onboarding owns accounts and invitations. | 'We use a modern stack and a clean architecture.' |
| 'What does the API between two domains look like?' | Endpoints with request and response shapes, errors included, one owner each. | 'The teams coordinate as needed.' |
| 'What do the tests cover, and can I watch them run?' | Tests per domain, including failure cases such as a refund issued twice. | 'QA happens before release.' |
| 'Who owns a domain when it breaks?' | A named engineer and team for that domain. | 'The team.' |
| 'How does the price change if I add a domain?' | Price tied to the number of domains and the weight of each. | One figure with no breakdown. |
What does a good data model answer look like?
It names tables and says who owns them. Payments might own invoices, payment attempts, refunds and a ledger. Onboarding owns accounts, invitations and verification state.
Each domain team owns its own tables, and other teams do not write to them directly. If onboarding needs a field from payments, the request goes through the API, or the payments team adds the column and ships the change that day.
Ask where the tenant boundary sits. In a multi-tenant product the tenant identifier belongs in the schema from the first migration. Adding it later is a project of its own.
Ask about data that changes over time, such as status fields, deletions and audit history. A partner who has thought about the data will have opinions. One who hasn't will say it gets sorted out in the sprint.
What does an API sketch tell you?
It shows where one domain stops and the next starts. The sketch is a list of endpoints, the fields in each request and response, and the errors that can come back. One page per domain is enough.
Check whether the endpoints use the language of the product, like POST /refunds, or the language of the database. Check how errors are described. A sketch that says 'returns an error' has not been thought through.
The API is also the contract the tests run against. If the sketch is vague, the tests will be vague too.
Where AI writes part of the code, the contract matters more. Generated code has to pass the domain's tests and match the API, and a named engineer owns the domain.
How does price follow the domain count?
Once each domain has a data model and an API sketch, the work is visible. You can count the domains. You can see which are plain, like admin, and which carry risk, like payments or an AI layer.
At Deciphering Logic we sketch the schema and API per domain first, and the price follows the domain count. The first call is about the schema.
It also shows how cost behaves later. Adding a domain adds a team with its own scope and backlog. The teams already running keep going without waiting on it.
We have shipped 30+ products for US and EU founders this way, and the pattern has held.
What are the warning signs on a first call?
The call is mostly about CVs and the logos of the tech stack. Nobody mentions tables. An estimate arrives in a day, with no questions about your data.
Everything sits in one backlog and one repository, with shared ownership of every part. When something breaks in production, the answer to who owns it is 'the team'.
None of these ends the conversation alone. Taken together they suggest the schema will be decided under deadline pressure.
How do you check the answers are real?
Ask to see a sample. A sketch from a past project, with client details removed, shows how the partner thinks.
Ask them to walk through one migration. Which team ran it, which tests changed, who signed off.
Then try a small version on your own product. Pick one domain, ask for its tables, API and tests, and have your own engineer read them.
If your engineer can read the API and the tests and start work the same week, the handover works. If it takes three meetings to explain, the structure is hiding something.
FAQ
How do you evaluate a software development partner technically?
Ask for a data model and API sketch per domain, tests you can watch run, and a named owner for each domain. Compare the answers with what your own team would write.
Should price come before the technical discussion?
A price given before the data model is a guess about scope. Get the sketches first and let the price follow the domain count.
How much of the data model do you need up front?
Tables, keys and ownership per domain. Not every column. It should be enough to see where tenant boundaries and shared data sit.
If you want to see how this looks across a whole product, the domain team model is laid out on our teams page.