The questions buyers
actually ask us.
Twenty-one of them, answered the way we answer them on a call — including the ones where the answer is no, we do not hold that certification, or no, you probably should not build this. If your question is not here, ask it and we will add it.
What it costs, and what moves the number
What does a project actually cost?
We give you a range on the first call. Not a number we then defend for six weeks — a range for work of a similar shape, with the assumptions written down so you can see what would move it. Most clients start with a discovery engagement and move into a build; programme and retained arrangements follow from there. The pricing page sets out the four shapes and what sits inside each.
Why will you not publish a fixed price list?
Because the same feature can differ by a factor of three depending on what it has to connect to. A build that talks to one documented API is not the same job as one that talks to a legacy system without one, even if the screens look identical. Publishing a single number would mean padding every estimate to cover the worst case. We would rather show you the levers and let you pull them.
What makes a project cheaper?
Six things, in roughly this order of impact. How many systems the build has to talk to, and whether they have documented APIs. Whether the workflow is already documented and agreed internally — if three people describe it three ways, discovery takes longer. The number of distinct user roles, because two roles is closer to three times the work than twice. Compliance requirements such as audit trails and data residency, which are all buildable and all add scope. Data migration, which is frequently the largest single line item and the one most often left out of a first estimate. And decision speed on your side: the cheapest projects have one named decision-maker who replies within a day. That last one is genuinely the largest variable we see.
What is included that other suppliers charge as extras?
Testing, code review, documentation, environment setup and handover material are part of delivery on every engagement, at every size — not line items. If a competing quote lists them separately, that is worth comparing carefully, because it usually means the base number is not what it appears to be.
Do we have to replace the tools we already use?
Usually not. A large share of the value is in connecting systems you already pay for — Google Workspace, your CRM, Razorpay, WhatsApp. We recommend replacing a tool only when keeping it costs more than moving off it. Replacing working software is expensive, disruptive, and frequently solves a problem the business did not have.
Discovery, delivery, and when we say no
What happens on the first call?
You describe the process and the constraints. We tell you the shape of engagement it needs and roughly what that costs, including when the honest answer is that you do not need us. There is no deck, and nobody will chase you afterwards.
Why do you insist on discovery before quoting?
Because a description is a summary, and summaries drop exactly the detail that determines cost. A finance lead will describe invoice approval as three steps. Watching it, there are eleven, and four of them exist only because a system two departments away exports a file in the wrong format on Thursdays. A supplier who quotes from a description is pricing the summary — you pay for the eleven steps either way, the only question is whether that happens in the estimate or in the change requests. We wrote this up in full: map the process before you quote it.
Can you work alongside our in-house team?
Yes, and it is often the better arrangement. We can specify and hand off, pair on delivery, or take a defined slice with a clear interface while your team keeps the rest.
Will you ever tell us not to build something?
Yes. Automation is a multiplier, and multipliers do not care about the sign of what they multiply — pointing one at a broken process makes the mess arrive faster. If the fix is a process change or a cheaper off-the-shelf tool, that is what we will say, including when it costs us the work.
What if the AI part gets something wrong?
Then the design was wrong. Anything customer-facing ships with confidence thresholds, human review on uncertain cases, and a logged trail so a failure is diagnosable rather than mysterious. Our governance page sets out the review thresholds, traceability and fallback behaviour in detail.
Ownership, certification and disclosure
Who owns our data?
You do. Data stays in your accounts wherever the architecture allows, access is scoped to what each system needs, and we document data handling in writing before a build starts.
Do you hold ISO 27001 or SOC 2?
No. We hold no formal security certification at present and will not imply otherwise. What we offer instead is documented practice — secrets management, code review on everything, dependency hygiene, environment separation and reversible releases — all set out on the governance page.
Will you complete our security questionnaire?
Yes, and we will answer it honestly, including the questions where the answer is no. Send it to officials@kaizensparktech.com.
What happens to data sent to AI model providers?
It is listed, scoped and disclosed before anything ships. Which components send data to a model provider, what they send, and what the fallback does when the model is unavailable are all documented on the governance page rather than left for you to discover later.
Paper, IP and who we actually are
Who owns the code when the project ends?
You do. Ownership of work produced under the engagement transfers to you on final payment. Pre-existing components and open-source dependencies are listed with their licences at handover, so you know exactly what you own outright and what you hold under licence.
Will you work under our MSA and NDA?
Yes. We work under your MSA, NDA and supplier terms where you have them, rather than insisting on our paper. Each engagement has a statement of work of its own.
Are you a registered company?
KaizenSpark Tech Private Limited, incorporated November 2024, registered in Tamil Nadu, India. Registration details are available on request for vendor onboarding — ask and we will send them.
Why are there no client names or case studies on this site?
Because we do not publish client names, screenshots or figures without written approval, and most of our clients would rather we did not. That is why the work page describes builds rather than naming them. We would rather be the supplier who protects a client’s confidence than the one with the better-looking website. If you want references, ask on the call and we will arrange them properly.
Handover, support and leaving
What do we get at handover?
Architecture notes, environment setup, runbooks, the rotation procedure for secrets, and the documentation needed to operate the system. The test we apply is whether an engineer who was not on the project can run it from the documents without a meeting. Documentation is written during the build rather than after it, which is the only way it ends up accurate.
What are your response times?
They are agreed per contract and written into the statement of work. During a build the delivery team is available through the working week and reachable on the agreed channel; response commitments and any out-of-hours cover are set out in your agreement. We would rather commit to a number you can hold us to than publish a general promise that means nothing.
What if we want to take the system elsewhere?
You can. Documentation, runbooks and environment setup are delivered as part of the build specifically so you are not dependent on our availability. A supplier who makes leaving difficult is managing your dependency rather than your system.
Still not answered?
Describe the process and the constraints. We will tell you the shape of engagement it needs and roughly what that costs — including when the honest answer is that you do not need us.