Rent Technology or Build It? How Zerodha Moved From NSE NOW to Kite
Short answer: Rent proven technology while customer demand, workflow and compliance are still uncertain. Build only when a vendor constraint measurably limits revenue, service or risk control, and when your customer base can fund both development and continuing operation. Before switching, require a tested migration, named operational owner and a downside budget at least 50% above the initial build estimate.
Building creates control, but it also turns software uptime, security, staffing and regulation into permanent operating responsibilities. Renting is not surrender. It can be a deliberate way to buy learning.
The wrong trigger for building is embarrassment that the product is not proprietary. The right trigger is a costly constraint you can quantify.
Zerodha's rent, switch, then build sequence
Nithin and Nikhil Kamath started Zerodha in India in 2010 with limited capital. The business initially used NSE NOW, a trading platform supplied by the exchange, rather than building its own trading infrastructure.
Zerodha's company history says that after roughly 15 months, when it had about 7,000 clients and daily turnover around INR 1,000 crore to INR 1,500 crore, it moved beyond NSE NOW. The next platform was Omnesys's vendor-built NEST. That was a switch between external systems, not an in-house build.
Ownership increased later and in stages. Zerodha's Pi history says it began work on the Pi desktop interface in January 2014 and Kite in October 2014, while retaining Omnesys's order and risk-management core. Its engineering account says the early technology team initially automated internal work and decided to build a usable web interface only after seeing the vendor's 2014 product.
The sequence matters: 7,000 customers justified a vendor change, not proprietary technology. Later operating knowledge and a visible interface constraint justified building selected layers while continuing to rent the commodity execution core. Public sources do not supply the vendor cost, in-house budget, outage history or migration losses, so they do not provide a complete financial case.
My view is that a first-time founder should rent any reliable, non-differentiating system that lets the business serve customers now. Build status is not a moat. Proprietary technology becomes defensible when it embodies operating knowledge and solves a verified constraint better than the market can.
Use the Rent-Build-Control Matrix
The Rent-Build-Control Matrix scores six dimensions from 1 to 5. A higher build score means ownership has greater potential value, not that you are ready to build.
| Dimension | Rent favoured when | Build favoured when | |---|---|---| | Differentiation | Customers barely notice the system | Workflow is central to why they choose you | | Constraint cost | Vendor limits are occasional | Limits cause measured lost contribution | | Failure exposure | Vendor owns response and recovery | You can operate incidents better | | Requirement stability | Needs are changing monthly | Core workflow has stayed stable for two cycles | | Team capability | No permanent technical owner | Named team can build and run it | | Financial capacity | Build threatens runway | Downside budget and operation are funded |
Score rent and build separately, then document the evidence. Do not average away a fatal weakness. A build with no security owner remains unsafe even if every other score is high.
Measure the vendor constraint
For 60 days, log every time the rented system blocks or degrades a customer outcome. Record customers affected, staff time, refunds, lost sales and risk. Separate inconvenience from economic damage.
If a missing workflow costs 20 staff hours monthly, its burden may be smaller than maintaining a custom system. If recurring outages lose £12,000 contribution and damage regulated reporting, control may be worth much more.
Ask the vendor about roadmap, service levels, exports, pricing tiers and integration before assuming a build is necessary. A configuration or contract change may remove the constraint for a fraction of the cost.
Price ownership beyond development
The build budget must include discovery, design, testing, migration, parallel running, security, documentation and contingency. The operating budget must include hosting, monitoring, incident cover, maintenance, compliance changes and staff turnover.
As a working guide, add at least 50% to the initial development estimate for the downside case. This is not an industry statistic. It is a protection against omitted work. Replace it with evidence from comparable projects when available.
Use the same time horizon for rent and build, usually 24 or 36 months. Discounting can refine a large decision, but a simple cash schedule is better than false financial precision.
Protect exit before dependency grows
Before signing with a vendor, confirm data ownership, export format, termination support, notice, subcontractors, service levels and price-change terms. Test an export while the relationship is healthy.
The guide on [finding and vetting suppliers](/operations/finding-and-vetting-suppliers/) applies to software vendors as much as manufacturers. Speak with customers who have experienced failure or left, not only references selected for satisfaction.
Data protection, financial services, record keeping, accessibility and outsourcing rules vary by country and sector. A regulated business may remain responsible even when a vendor performs the work. Obtain qualified local legal, compliance and security advice.
Worked example: TradeCore Brokerage
TradeCore Brokerage has 8,200 active customers and rents a trading platform. These figures are illustrative.
The vendor charges £1.85 per active customer monthly plus £4,000 fixed support. Monthly rent is 8,200 x £1.85 + £4,000 = £19,170. Vendor limitations also require 190 staff hours of manual reconciliation at £26, costing £4,940. Total monthly burden is £24,110.
A custom platform is estimated at £310,000. TradeCore uses a 50% downside allowance, giving a build case of £310,000 x 1.5 = £465,000. Ongoing hosting, security and maintenance are forecast at £13,500 monthly.
| 36-month option | Calculation | Cost | |---|---:|---:| | Rent and manual work | £24,110 x 36 | £867,960 | | Build downside plus operation | £465,000 + (£13,500 x 36) | £951,000 |
On direct cost alone, building is £83,040 dearer over three years. TradeCore also documents £7,000 monthly contribution lost because the vendor cannot support a demanded order type. If a custom system recovers only half, 36-month benefit is £3,500 x 36 = £126,000. Adjusted build cost becomes £825,000, £42,960 below renting.
That still does not authorise the project. TradeCore requires two pilot brokers, a tested migration of 200 accounts, an independent security review and 12 months of build funding ring-fenced. The matrix converts “we need control” into testable conditions.
Decide whether the timing is right
Even when building wins over three years, starting now may be wrong. Check whether requirements have remained stable, a technical and operational owner exists, and the business can survive six months of delay without cutting customer service.
Consider a staged alternative: keep the vendor for execution while building the differentiating interface, data layer or workflow. Partial ownership can remove the costly constraint without recreating a mature platform.
Run a 60-day pre-build decision
In week one, open a constraint log and collect the current contract, invoices and incident record. By day 20, quantify customer and staff impact and ask the vendor for remedies. By day 30, obtain two external build estimates and a maintenance view.
During the next 20 days, test data export, design a small migration and name the operating owners. On day 60, approve rent, renegotiate, stage a partial build or fund the full build. Do not begin code before you can state the constraint in pounds and affected customer outcomes.
Related guides
Frequently asked questions
Is building cheaper once customer numbers are high enough?
Sometimes, but customer volume alone does not decide it. A per-customer vendor fee can make ownership attractive at scale, while security, support and maintenance create substantial new fixed costs. Calculate both options over the same 24- or 36-month period and include migration, parallel running and a downside build estimate. Then add the contribution recovered from removing genuine vendor constraints. A simple break-even customer count is useful only if usage, service level and staffing remain stable. Recalculate when those assumptions change.
How many customers should I have before building?
There is no universal threshold. Zerodha's reported 7,000 clients provide context, not a rule. Build readiness depends on stable requirements, economic constraint, team capability and funded downside. A specialist product with 80 high-value customers may justify ownership sooner than a free consumer product with 50,000 users. Set your threshold from the contribution or risk the build can recover. Require evidence from actual customers and operations, not projected sign-ups. Customer count without unit economics can magnify an expensive mistake.
What if the vendor could become a competitor?
Assess access to your customers, data, pricing and workflow under the contract. A theoretical competitive threat does not automatically justify a costly build. Reduce exposure through data portability, brand ownership, customer relationships, contractual restrictions where enforceable and a tested alternative. If the vendor controls the customer interface and switching is impractical, strategic dependency is higher. Competition and contractual restrictions vary by jurisdiction, so obtain qualified local legal advice. Keep proprietary the operating knowledge that genuinely differentiates you, even while renting infrastructure.
Should I build a complete replacement or one component?
Usually start with the component that causes the measured constraint. A proprietary customer interface, reconciliation layer or reporting workflow may create most of the value while a vendor continues providing commodity infrastructure. Define clear boundaries, failure ownership and data flow. Partial builds add integration risk, so test end-to-end recovery rather than assuming each component's uptime will combine neatly. A complete replacement is justified when integration itself creates the constraint or regulated responsibility requires deeper control, and only when the permanent operating capability is funded.
How do I compare vendor downtime with my own likely downtime?
Use incident frequency, duration, customers affected, contractual remedies and actual response from the vendor. For the build case, do not assume perfection. Model staffing coverage, monitoring, recovery time and the cost of at least one serious incident. Ask an experienced independent operator to challenge the plan. A mature vendor may be more reliable than a small internal team even when its service feels impersonal. Ownership improves your ability to act, but it also makes every failure yours to diagnose and fund.
What should I negotiate before renting core software?
Prioritise data ownership and export, service levels, incident communication, security evidence, price changes, termination assistance, subcontracting and liability. Define which party supports the end customer and how urgent failures are escalated. Test integrations and an export before signing a long term. Do not rely on a sales demonstration for operational behaviour. Requirements and enforceability vary by jurisdiction and sector, particularly for regulated outsourcing and personal data. Have qualified local legal and security professionals review material arrangements before customer dependency grows.
Comments (0)