Discovery
We sit with the people who will actually use the system and write down how the work happens today, workarounds included.
One contract, one point of accountability, and a written trail from the first conversation to the annual support review. This page sets out how that actually works in practice, including the parts most suppliers leave until the contract is signed.
Most businesses do not have an IT problem. They have four or five suppliers, and none of them will own the outcome when something breaks at nine on a Monday morning.
The hardware came from one firm, the software from another, the network from a third, and the person who set up the backups has not answered an email since March. Every one of them is technically correct about whose fault it is not. The business, meanwhile, is not running.
Kimika IT Solutions was founded to close that gap. We take responsibility for the whole chain: specifying and supplying the equipment, designing the network and cloud estate that runs on it, building the software the business actually works in, and then staying on to operate all of it.
We are deliberately small and deliberately senior. Every engagement is scoped by a director and delivered by engineers who were in the room when the scope was written. There is no account layer sitting between you and the people doing the work, and no stage at which your project is handed to a team that has not met you.
One contract, one point of accountability. We do not divide responsibility between suppliers and leave you to arbitrate. Where a third party is genuinely required, we hold that relationship rather than introducing you to it.
Source, schema, asset registers and runbooks get handed to you, not held over you. Your environment remains yours, and a competent engineer who has never met us should be able to pick it up from the documentation alone.
Service levels are written into the agreement and reviewed monthly against the actual numbers, including the months we miss. A report that only ever shows green is not a report.
These are not extras and they are not priced separately. They apply to a two-week website as much as to a multi-campus platform rollout.
One of the two directors is accountable for your engagement by name, from scoping through to the support review, and you have their direct number.
Screens, modules, integrations, assumptions and a price, with the exclusions listed as plainly as the inclusions. Changes are quoted before they are built.
Progress is shown on a real screen against real data. We do not report completion as a percentage, because nobody has ever been able to verify one.
Architecture notes, database schema, deployment steps, credentials handover and an asset register, delivered at go-live rather than promised for later.
Domains, cloud subscriptions, gateways and store listings are created in your name and billed to you. We hold access; we do not hold the keys.
If you ever move to another supplier, you leave with the source, the data in an open format and the documentation. There is no fee attached to that.
No stage begins until the previous one is accepted in writing. It slows the opening slightly and saves the rework that usually eats the back half of a project.
We sit with the people who will actually use the system and write down how the work happens today, workarounds included.
A fixed written scope with screens, modules, integrations and a price. Exclusions listed as clearly as inclusions.
Two-week cycles, each ending in a working demo. You see progress on a real screen, not in a percentage.
Data migration, a parallel run where the risk warrants it, and training given to the staff rather than to the manager.
An AMC with response targets in writing, plus the documentation you would need if you ever changed vendor.
A build takes a few months. Running it takes years, which is where most of the value and nearly all of the frustration lives.
Response targets by severity, written into the agreement rather than described in a brochure. Critical faults are covered around the clock; everything else runs to office hours.
Small changes are absorbed into the contract; anything larger is quoted in writing before work starts, so a support agreement never quietly becomes a development budget.
Ours are below. We would suggest putting the same list to anyone else you are considering.
Yes, on final payment, for anything built specifically for you. Our School & Department Management System is licensed rather than sold, because it is a product with other customers on it — but your data, your configuration and your integrations remain yours in an open format at all times.
You take the source, a database export, the credentials and the documentation, and you go. We will answer reasonable questions from the incoming supplier for thirty days. There is no exit fee and no clause that makes leaving expensive.
Defined projects are fixed-price against a written scope. Ongoing work is either a monthly retainer or an annual maintenance contract. We do not bill by the hour for scoped work, because that puts our interest and yours on opposite sides.
Frequently, yes. Where responsibilities overlap we ask that the boundary be written down — who owns the network, who owns the application, who is called first — so that an incident does not turn into a discussion about scope.
In your own AWS or Azure subscription wherever possible, in an Indian region unless you ask otherwise. If you prefer on-premise, we will build for on-premise and say plainly what that costs you in resilience.
Small enough that a single website or a hardware rollout is worth the conversation. What we will not do is take on work we cannot support afterwards, so we will occasionally decline something and tell you why.
Kimika IT Solutions Private Limited is a company limited by shares, registered with the Registrar of Companies, Pune, Maharashtra.
A first conversation costs nothing and is held with a director. If we are the wrong firm for the work, we will say so and point you at the right one.