When a Startup Should Rewrite Its App and How to Hire Engineers Who Fit the Team

A startup should rewrite its core software the moment repeated failures stop it from shipping features week to week, not at seed stage. Ajey Gore, former Group CTO at Gojek and Operating Partner at Sequoia, lays out a practical rule for scaling engineering teams, hiring creators, and evolving the CTO role.

When should a startup start worrying about scalability

What is the trigger point for rewriting systems

Gore sets a single clear signal for when founders should shift from building features to rebuilding infrastructure.

if you start going down or you can't roll out features week on week, that's when you start thinking about scalability.

He explains that at Gojek in 2015, the application went down every day at three o'clock because of load. The team did not pre-plan scalability at seed stage; they watched the breakdown and fixed one problem at a time. The priority order comes from customer impact. Booking must work first. If a driver appears five to seven minutes after booking, the customer tolerates unresponsive screens. But if booking itself fails, the core promise breaks.

you start solving those small issues: what is most important for customer, that's when you need to relook.

This step-by-step triage avoids rewriting everything at once, which wastes effort on parts that do not block revenue. A team should list its user flows, mark the one that loses money when broken, and repair that before touching secondary screens.

Why rewriting is better than patching

Once a system breaks consecutively for one or two weeks, Gore advises a full rewrite rather than layering fixes.

if you are making a race car, you can't put four normal cars together and make a race car; you have to discard everything and put a racing car to go faster.

He extends the analogy: a rocket ship cannot be ten racing cars bolted together. The sunk cost fallacy—"I have done this software let's fix it"—traps teams in slow code. Fixing stuff takes a lot more time than writing from zero. He uses a gaming metaphor. In Mario Bros, after learning tricks, a player finishes level one in under 60 minutes on a fresh save because the mistakes are known. Software is identical: a rewrite encodes hard-won lessons.

if you rewrite software you write better software. You already know tricks, mistakes to avoid.

At Gojek, the app was rewritten four times in four years: Objective-C to Swift 1.0 to Swift 2.0, Android Java to Kotlin. Backend location logic was rewritten six times in four months. It moved from a small geo based logic, to Redis Geo, then to Geo, then to Postgres Geo, then to the S2 library, and finally to Golang plus S2 library for performance reasons. Each move answered a specific scale limit rather than a vague future fear.

How to hire software engineers who are creators

Why code is the only true proof of skill

Gore treats engineers as creators like chefs or painters. Given one problem, four engineers produce four different codes.

How know good software engineer? Looking at their code.

He rejects credential checks. Ask for GitHub commits or public repos. If none, invite them to solve a small problem live. The method reveals thought process, not syntax memory. A chef is judged by tasting food, a musician by listening to music, a painter by viewing paintings. An engineer is judged by reading the program they wrote.

I want to see you solve it. Not because I don't trust you know language, but want to know how you solve it.

The three criteria for hiring an engineer

A hiring decision rests on three layers, not just technical score.

1. Technical ability from code sample – this is only 30 to 40 percent of the verdict.
2. Capacity to learn – if interviewed for a domain he does not know, judge whether he can pick it up.
3. Colleague comfort – can the panel sit next to this person for a year and feel good?

if interview somebody and three or four people, one says I don't feel comfortable, we shouldn't hire.

The first layer proves they can write. The second layer protects the startup from domain mismatch. The third keeps the team healthy as headcount grows past twenty or thirty.

Why interviews should aim to hire, not filter

Most panels hunt for faults. Gore flips the intent.

Go with intent to hire: find ways whether I can hire you, focus on good things, what you don't know we will teach.

This surfaces potential rather than punishing gaps. A candidate who answers poorly in a verbal interview may still be a talented coder; the live task shows the truth. The panel should list the candidate's strengths and ask "how can we bridge the rest?" instead of "where did they fail?".

How to run probation without losing dignity

What probation should test

Probation is for personal skills, not coding tests. Some engineers cannot sell themselves in interviews yet code well. Gore uses three months to observe. The red line is refusal to unlearn. He gives an example of an engineer who insisted on Fedora while the team used Ubuntu.

we comfortably say: you are amazing, but not fitting in, find next job comfortably and leave.

The test is whether the person can adopt the team's working style. Smartness alone does not save a misfit who blocks collective rhythm.

How to let someone go respectfully

When probation fails, Gojek gave the person three more months salary and permission to say they still worked there.

when somebody comes in they come with hope, trusted you; when go away must go with same respect.

Only about five of every hundred people failed probation. The rest passed because the hiring process already filtered on fit. The extra pay lets them leave without financial shock and preserves their career story. Most understood and moved on.

How to upskill existing engineers

Peer learning and Thursday sessions

Weak engineers improve by pairing with strong ones. Gore rotated an Android expert into backend tasks.

Surprised how fast people learn from each other.

Weekly Thursday lunch talks had one engineer teach another team. DevOps explained deployment to food team; food team taught DevOps about Kafka misuse. He also ran monthly AMAs where anyone could ask anything. External workshops fail when people return and do not apply the skill, so internal transfer is preferred.

Thursday learning sessions most important, learn over lunch popular.

Budget for courses and books

The company reimbursed Udemy courses after certificate. Book budget allowed each person up to 2 million rupiah yearly, or up to 1 million rupiah in some cases, to buy technical books left around the office.

you must have intent, go get certificate you pass, here is money, no issues.

Engineers from data engineering took data science courses and were paid back only after passing. Books were bought from Bangalore or online and placed in common areas for anyone to read.

How to find a CTO co-founder in Indonesia

Look for hustle, not just years of experience

Gore notes Indonesia's software wave started around 2010, later than India's 1980s, but banks produced strong Java engineers. Gojek Indonesia had around 400 software engineers versus 300 in India, proving local talent exists at scale.

You can find them too; they are there, just don't come out, very good engineers, need a little help.

A young founder should seek a partner with five or even three years experience, any language, if they show curiosity and hustle.

People with hustle are the ones you want to hire; he doesn't have to have 15 years experience.

The CTO.id WhatsApp group connects such talent with founders.

Bring Indonesians abroad back home

Gore recruited Indonesians living in Los Angeles by inviting them to Gojek events.

please come back to Indonesia, we are Gojek, we do nice things, please come back.

Exposure builds the local ecosystem. Founders should attend overseas Indonesian community meetups and pitch the mission, not just the salary.

How the CTO role changes as the company grows

The four stages of CTO

Gore maps four personalities across funding stages.

1. Founder CTO – writes scrappy code, gets product off ground.
2. Execution CTO (Series A) – manages delivery, still codes.
3. Management CTO (Series B–D) – leads leaders, needs extroversion and empathy.
4. Strategic CTO (Series F+) – complements CEO, executes vision.

Early stage you need a hustler. Second you need a builder. Third stage you need a caretaker. Fourth stage you need an owner.

The management stage requires extroverts because the job is connecting outside the team. An introvert who stays inside becomes a bottleneck. The strategic stage needs a person who treats the company like a house owner surveying every corner.

Why stepping down from title is healthy

Gore left Gojek because he could not balance family and health at thousand-person scale.

The title is always ephemeral, it's gonna go away.

He advises optimizing for respect as a person, not a role. A founder can stay as co-founder enabling others. If you were CTO of a ten-person company but not capable of CTO of a thousand-person company, bring in the better CTO and remain as an enabler. Holding the title too long makes you optimize for the label and do stupid things.

How to bridge business and engineering

Why business feels engineering is slow

Thought speed differs from implementation speed. Imagining a trip to airport is instant; actual travel takes hours.

Engineering is driving car on road; business is starting car.

The spinning wheel example shows the gap: an engineer made the loading icon spin faster so the product manager thought the software was faster. That illusion breaks trust. Business must see real progress, not theater.

Show deploys and uptime constantly

Gojek deployed at least hundred times daily, 3000 to 5000 times per month. A Slack channel let business see each deploy.

We had production deploys Slack channel with business people, they see and get happy.

A deployment page showed counts. Dashboards displayed uptime, tickets closed, incidents. Office cleaners are never thanked until they skip a day; software is the same—its value shows only when it fails. Constant update trickle prevents surprise.

Making them part of your journey is super important.

Teach business with books

Gore gave Nadeem "Continuous Delivery" and "The DevOps Handbook" so non-engineers grasped constraints. He recommends "The Goal" and "The Mythical Man Month" as well. A business leader who reads these stops asking why a feature takes two weeks.

How to build cross-language team culture

Teach local languages to all offices

Gojek ran Bahasa and English classes. Friday was English day; other days any language.

Language: if you don't practice you lose touch.

Indian and Singapore staff took Bahasa classes to feel the gap. Speaking slowly in either language kept meetings inclusive. Google Translate live mode helped when words failed.

Flatten hierarchy and rename HR

Open floors, no cubicles. HR became "people department". Sick leave unlimited. He banned "blacklist/whitelist" for "block list/allow list" to remove color bias from colonial legacy.

Semantics affect perception.

Renaming shifts how staff see each other from resources to humans. No leave approval meant trust; anniversaries had local bands. The culture came from early tolerance choices, not memos.

Key Takeaways

• Rewrite systems only when outages block weekly feature releases, not at seed stage.
• Hire engineers by reviewing their code and judging learning ability and team fit, not by fault-finding.
• Run probation to test openness to learning; let misfits go with pay and dignity.
• CTOs evolve through four stages; step down from title when personal limits hit to serve the company.
• Bridge business and engineering by streaming deploys and uptime, and teaching with standard books.