Limited-time dealSupermicro HGX B200, 8 GPUs8-GPU NVIDIA HGX B200 server in stock
View the specification Call +91 92058 93902innovations@udhyamlabs.tech
Our work is to take a proof of concept through to a system that your own team runs.
This page sets out one problem we work on, how we approach it, what we do at each stage, how the other routes open to you work, and what we add. The firm is new and has no client work to show yet, so the page describes how we work, and the experience behind it is our engineers' own from earlier roles.
A proof of concept has not yet been asked what production asks
Many businesses are testing new technology. Most of that testing is in AI, and some have begun to test newer fields such as quantum computing. Testing is the right first step, because which technology suits a business can only be found out by trying it on that business's own work.
A proof of concept, or a pilot, answers one question, which is whether the technology can do the job on a chosen sample. It is usually built by a small team, on sample data, for a few users, with wide permissions and nobody on call. That is appropriate for a test. Production then asks six further questions.
Is it right on your real data?
A proof of concept is usually judged on a sample that was chosen for it. Accuracy has to be measured on cases drawn from your own work, with a correct answer agreed for each case. The system also has to read that data from the systems of record that hold it.
Does it hold at peak load, and what does it cost there?
Response time has to be measured at the concurrency you expect at peak, with the mix of requests you expect, and then beyond that point until it degrades, so that the margin is known. The cost of each type of request is measured at that load, and the monthly cost is calculated from it and from the volume you expect.
Who and what can reach it, and what can it reach?
A test is often run with wide permissions. Production needs an answer for each component: who and what can reach it, what it is permitted to reach and do, what data it handles and stores, where its secrets are held, and what leaves your environment.
What can you show an auditor?
An auditor asks what the system did, on which data, and who approved each change. The first two come from logs that the system has to be built to keep, with a retention period and protection from alteration that you specify. The third comes from your own change approval. Both have to be designed in from the start, because neither can be reconstructed afterwards.
How does it fail?
Any component can fail. Production needs to know, for each failure that can be foreseen, its effect, how it is detected and how long recovery takes. Recovery time is known only once the recovery has been rehearsed. For an AI system a wrong answer is also a failure, and it leaves every health check green.
Who owns it and who runs it?
The team that built the proof of concept is usually not the team that will run it. Your own engineers have to be able to release it, roll it back and operate it, and someone has to be on call. A named owner in the business has to accept it. In a regulated business your risk and compliance functions also have to approve it.
In our view it is uncommon for one implementation partner to be set up to take a proof of concept through all six and to put each answer in writing. Our own work is in AI systems, cloud and platform engineering, and the sizing of the hardware beneath them. If your proof of concept is in a field outside those, such as quantum computing, we say so in our first reply, and where we know a firm better suited to it, we name that firm.
We explain each component, and we say where our knowledge of it comes from
Our engineers assemble and test the system themselves, component by component. The approach rests on four practices, and each is set out in more detail elsewhere on this site.
We trace a problem to the layer that causes it
Our engineers work in the framework and the infrastructure code, and they read the source when the fault is there. For a component whose source is closed, such as a model reached through an API or a managed cloud service, we rely on what we measure and on what its supplier documents.
How we engineerA lead and a second engineer, accountable for every layer in scope
Every engagement has a lead engineer and a second who follows it from the first day and can take it over. A fault that crosses two layers in scope has one owner, and a fault that reaches outside the scope is reported to you.
People and continuityNothing is subcontracted
All engineering is done by engineers engaged directly by Udhyam and named in the statement of work. The engineer who explains a component to you is one of the engineers who deployed and tested it.
How we are builtWe measure before we design
We measure the proof of concept on your own cases before we propose a design. Each later decision is recorded with the measurement behind it, or with a statement that it rests on judgement.
How we verify a moveWhat we do at each stage, and what each stage is planned to leave with you
For an AI system, the test is the fixed-fee assessment described under Working with us. The two stages after it make up the build, which is done in milestones, and the last is the handover. For the other practices, the assessment is the one that the Services page describes.
Test
We agree with you what a pass is before the test starts. The proof of concept is then measured for accuracy on cases drawn from your own work, and for response time and cost at the concurrency you expect at peak. A figure that could not be measured in the assessment is marked as calculated. If the proof of concept does not pass, the findings say so, and you can stop there.
Planned to leave you withThe measured results, the evaluation cases, and a short paper for your management: whether the system can reach its targets, what that would take, an estimate of the cost and what could go wrong.
Design for production
This is the first milestone of the build. Each component is examined for who and what can reach it, what data it handles and how it fails. The design states its expected load, its cost and its target recovery time, and says for each figure whether it is measured, calculated or a target. Your architects and your security team review it against criteria agreed in writing beforehand.
Planned to leave you withThe production design, with a component map, a data flow map, a register of failure modes and the cost model.
Scale
The system is built out to the concurrency you expect at peak, in milestones, inside your own accounts. The access rules, the logging and the alerts set out in the design are built in these milestones. Each milestone has acceptance tests agreed in writing before work on it starts, and a step that cannot be reversed runs only with your sign-off.
Planned to leave you withThe working system, its infrastructure code and the measurements for each milestone.
Hand over
Your engineers run the system, a release and a rollback themselves while ours observe. A support period follows, and its length is set in the statement of work. Continued engineering is available on a retainer if you want it.
Planned to leave you withThe runbooks used in those runs and the decision record.
Before the test starts
If you have not yet chosen the technology
The options to be compared are named before the fee is quoted. Each is measured on the same cases and at the same load, and the findings compare the results. Where there is no proof of concept yet, the assessment works from stated inputs and says how uncertain the result is.
What the test needs from you
You provide a sample of real requests and people who can say which answers are right. Cases that contain personal or cardholder data are masked first, or are kept in a store that you designate.
What you can see while the work is under way
Four documents are kept in your repository during the build, and the statement of work lists them. We work in writing by default, so you can follow progress without a call.
Each component described
You see a written description of each component in the agreed scope, which states what it does, what it depends on and where its limits are. It says whether one of our engineers has run that component in production and whether its source is open to us.
What can break
You see a register of the failure modes we have identified, ranked by severity. Each entry gives the cause, the effect, how the failure is detected, how the system recovers, and whether we tested it or took it from the component's documentation. It includes wrong answers as well as outages.
For your security team
For each component in the agreed scope, the document states who and what can reach it, what it is permitted to reach and do, what data it handles and stores, where its secrets are held and what leaves your environment. It is written for your security team to review and test, and it is not a penetration test.
For your auditors
Each design decision and each test result is recorded in your repository when it is made, and each change passes through your change approval. That is the record of the build. The evidence that your controls operated after the system went live is produced by your own team, from the logging built into the system.
We do not audit or certify the systems we build, and we do not issue security or compliance certificates. These documents are written for your own security team and your auditors to examine, and whether they meet their requirements is for them to decide. Our own access is part of the answer: we work under named identities that you issue and can revoke, and we do not copy production data out of your environment.
How the other routes to production usually work
A business with a proof of concept that works has several other routes to production, and they can be combined. We work alongside your own team and your existing suppliers, and a vendor or an integrator can remain responsible for its own part.
The table describes each route as a kind of firm, in general terms and in our own view. It does not describe any particular firm, and individual firms differ. The last row states where we are the weaker choice.
What it is set up to do wellIt knows its own product in depth and can deploy it quickly. Where its managed service fits the use, there is less to build and less to run.
What it leaves openThe layers the vendor does not sell, and an independent view of whether its product was the right choice.
What it is set up to do wellIt knows its own cloud in depth, and its catalogue reaches from the hardware to the model.
What it leaves openIt designs for its own cloud. A comparison with another provider, with a sovereign or private cloud, or with hardware you own is not what it is set up to give. Delivery is often passed to a partner firm.
What it is set up to do wellIt can staff a large programme in many locations for several years, with established governance. It often knows your existing systems and can operate what it builds under a service level agreement.
What it leaves openThe work is commonly divided between specialist teams, and the engineers who build it are often different from the people who scoped it. A question about the internals may pass through several people before it reaches the engineer who can answer it.
What it is set up to do wellIt helps you choose which uses matter and builds the business case for them. Some of these firms also build.
What it leaves openWhere the firm does not build, the recommendation is implemented by someone else, and its value then depends on how completely the reasoning was written down.
What it is set up to do wellIt does the same kind of work as we do, with the same kind of team, and it may have client work to show.
What it leaves openWe are a firm of this kind, and the questions this page asks of us apply to any other. They are who does the work, what is put in writing, whether the firm covers the platform and the hardware beneath the model, and who pays the firm.
What it is set up to do wellIt operates systems day and night under a service level agreement.
What it leaves openIt usually takes over a system that is already built and documented, so the work between the proof of concept and that point still has to be done by someone.
What it is set up to do wellIt knows the business and its systems, and in most cases it will run whatever is built.
What it leaves openThe team often has a full workload already. Serving a model at load and sizing accelerator capacity may be work it has not needed to do before.
What it is set up to do wellIt is set up for a lead engineer and a second engineer to take the proof of concept through the test, the build and the handover, and to put what they find about each component in writing.
What it leaves openThe firm is new and small, and it has no client work to show yet. The team on an engagement is small, so work that needs a large team at the same time is beyond what we can staff. Your team runs the system once it is handed over. We do not audit or certify what we build.
What working with us adds to a proof of concept
Most of these can be checked against the documents and the system you hold when the engagement ends. The others are terms that the contract and the statement of work set out.
A decision that rests on measurements
The proof of concept has been measured on your own cases and at the concurrency you expect at peak. The decision to scale it, change it or stop it rests on those figures.
A system you can explain
You hold a written description of each component in the agreed scope, what it depends on and the failure modes we have identified. The documents belong to you and are written for your board, your security team and your auditors to examine.
The test and the build are done by the same engineers
If you ask us to do the build, the engineers who ran the test do it, so what they learned in the test is carried into the build. If the lead has to change, you are told first.
Advice with no supplier behind it
Our advice is paid for only by our clients, and no supplier pays us for a recommendation, so a recommendation to change the technology or to buy less costs us nothing. A recommendation to stop costs us the build, and the fee for the assessment is fixed whichever answer we give.
A handover that is tested
Handover is complete when your engineers have run the system, a release and a rollback themselves. The code, the configuration and the documents are in your accounts and your repositories.
A first step you can stop after
Every engagement starts with an assessment of fixed fee and fixed length. Capacity rented for its tests is billed to you by the provider, and our estimate of that cost is quoted beside the fee. If you stop when the assessment ends, you keep the findings and can take them to any other firm.
Describe the problem, and an engineer will reply within one working day
Tell us in general terms what you are trying to do and what has stopped it. If it is not ours to take on, we will say so.