Engineering rigour
We build software the way it should be built, designed, reviewed, tested and documented. Shortcuts that create problems for the client later are not savings.
An enterprise technology company built on engineering discipline, security-first thinking and long client relationships.
The company
How we deliver
Engineering, AI, cloud, security and delivery roles across Roorkee and Bengaluru.
View Open RolesEngineering, intelligence, cloud and security capability delivered through the engagement model that suits you.
Grouped by the result you are trying to achieve rather than the technology involved.
Sector knowledge matters. It determines which constraints are negotiable and which are not.
Regulated and public
Industrial and infrastructure
Commerce and services
By organisation size
We assess sector constraints as part of discovery on every engagement.
Get a Free ConsultationPractical writing on enterprise technology, drawn from delivery experience rather than vendor material.
About Acmez
What we are trying to build, how we intend to build it, and the standards we expect to be held to.
To be the enterprise technology partner organisations trust with the systems their business depends on.
To engineer secure, scalable and maintainable digital systems that solve real operational problems: delivered with technical rigour, commercial honesty and a commitment to long-term partnership.
Our values
These are written to be testable. If we fail one of them on your engagement, you should be able to point at it.
We build software the way it should be built, designed, reviewed, tested and documented. Shortcuts that create problems for the client later are not savings.
Access control, encryption, logging and least privilege are part of the design. Security added afterwards is always weaker and always more expensive.
We say when a packaged product would serve you better than a custom build, when a technology is unnecessary, and when an estimate has grown. Losing work is preferable to misleading a client.
Clients receive plain explanations of technical decisions and their trade-offs. If a recommendation cannot be explained clearly, it usually is not well understood.
We take responsibility for outcomes, not just deliverables. When something we built causes a problem, we fix it without argument about scope.
We document, transfer knowledge and build systems clients can maintain themselves. Dependence created deliberately is not a business model we are interested in.
Next step
We publish what we will and will not do. If our approach fits how your organisation works, we should talk.