The article below is adapted from a talk I gave to the first cohort of the Antler startup generator in Nairobi. I aimed to give some practical advice for technical and non-technical founders aiming to build tech-enabled businesses.

Google is huge. Your startup is a comparative minnow. You’re a small fish in a big pond. To survive, you’ll have to think and act like one.

You don’t have an army of developers but you can fit your whole team round a dinner table. You can’t roll out a product around the world but you can call each one of your customers personally. Technical decision making is totally different at either extreme.

I’ve spent most of my career at small companies. My previous role as startup CTO at Housekeep gave me 6 invaluable years of experience of not being Google, and I’d like to share all the counterintuitive advice that got me through that time. The advice that eventually helped Housekeep grow into the success story it is now, with over 2.6 million hours of cleaning delivered.

I’m now using these strategies at Pariti, where we’re exploring ways to improve the survival chances of small fish in the stormy seas of a global pandemic.

So here are 8 strategies to bear in mind as you make your plans to be the next Google.

You can use uncool technology

When developers meet each other, they always work their way around to a loaded question: what’s your stack? This is shorthand for all the technologies that they’re bringing together to deliver their product. It’s their technological foundations, walls, windows and roof.

Google has an awe-inspiring stack. They own and manage every element from the physical buildings all the way up to the code that runs in your browser. Google owns everything, and everything is cool.

You, as a startup, should be aiming for a new and better way of tackling some human problem. That will require cool new approaches, cool new thinking, cool new processes.

But 99% of startups won’t sell pure technology. They will sell a solution to a problem that is delivered with technology’s help. This means you should be focusing all your energy on the higher layers of the stack where you craft your solution. Meanwhile and all the foundational layers should be boring, safe choices.

A boring technology has known flaws and tradeoffs. It’s been around long enough to have a big user base, and these users have uncovered most of the serious bugs. You’ll be able to find developers who have built up years of experience with it. By contrast, exciting technologies have unknown flaws and hidden trade-offs that emerge at inconvenient times.

HIRING WHEN YOUR TECHNOLOGY IS NOT COOL

One problem in this approach is that developers get a buzz out of cool new stuff. They also know that there can be a salary premium attached to the latest frameworks or databases. This leads to a conflict of interest: they encourage you to adopt exciting new tech, so they get free experience of the new stuff, which they can use to command higher salaries working somewhere else.

You have to be aware of this and ensure they are not making stack choices that will bite you later. Meanwhile the developers you actually want on your team are the ones interested in solving problems and shipping good products.

Google can hire developers motivated only by technology because it has the coolest stack. You cannot. You need developers that are motivated by solving the problem you’ve chosen to solve.

You can sit developers with users

One sign that a developer cares about your problem is if they’re willing to spend time with your users.

Google puts their developers in quiet, stylish, spacious cocoons where they can focus intently on building Google’s incredible systems. You, on the other hand, want to put yours right in the thick of it.

In the earliest days of Housekeep we didn’t have full blown apps for our customers and cleaners yet — we communicated with them by telephone and email. The only direct users of our tools were our customer service reps. At this point in our history, we sat our developers next to our customer service people. This was 20% by strategy and 80% because we were paying by the desk in a tiny shared office.

But it proved to be a good decision. I could hear when our head of customer service was struggling with a particular problem, and she could give me immediate feedback as I solved it. We could also move fast and break things safe in the knowledge that we would physically hear if new code was causing slowness or bugs.

So as the team grew, we kept this as a guiding principle of our office culture. Developers should be able to overhear problems and fix them before users have made a bug report. It didn’t work forever — eventually we had to put more processes in place to operate more strategically. But those early days informed the culture that followed: responsive developers getting immediate positive feedback as they solved real users’ problems.

Google has an enormous number of employees devoted to gathering user feedback and translating it into actions for developers. You can do the same with careful hiring and a seating plan.

You can choose when to follow best practices

Google is building a global system that has to be online 24/7 without fail. Their systems are engineered to the extreme. When you’re not Google, you can break the rules a bit.

Of course your developers should not be breaking every rule every day. You are handing control of your vision to the people who code it, and you should be able to trust they are building it to a high specification.

Let’s think through an important example: automated testing. Broadly, this means that the developer writes code to implement features, and she also writes code to check that the features are working. I always drill tech interviewees about their testing practices, and if any of them told me that they didn’t believe in testing the interview would be over.

But on the other hand, doing things properly is time-consuming. If you’re a young company and your product is in flux, you could find yourself throwing away large parts of your codebase when features get superseded.

The best strategy is a mixed one. Sometimes you do need a very high degree of confidence. Our billing and payments code were always fully tested. But early on, any code concerned purely with displaying things to the user went without automated tests. The users would tell us if it was wrong, and we would fix it. In addition, we knew our UX was going to change rapidly, and tests would have made it more rigid.

Everything between those two extremes was a judgement call that had to be hammered out amongst the team members. My ideal startup engineer knows why following best practice is important, and knows when and where to bend the rules.

You can borrow against the future

Leaving parts of your system without tests is a classic example of technical debt: you can do things sloppily to increase your velocity, all the while knowing that you will need to go back and do it properly at some future date.

There should be a healthy tension between you and your developers. They’ll say “we want to do this carefully so that it lasts 10 years” while you say “build it fast so we can see if anyone actually wants this thing.” Every time you win this argument you have taken out technical debt, and it’s going to compound over time as you build more and more quick hacks.

These conversations about what to build properly and what to hack together need to happen out in the open. Your company should be religiously using issue tracker software to log all the features you want to build, and all the quick hacks that you need to fix. It will be vital later when you need to know where all the bodies are buried.

You can break things and get away with it

When Gmail goes down for ten minutes, it seems like the whole world is panicking. By contrast, while your user base is small and your product relatively simple, you can take calculated risks. Rapid iteration might break things but the consequences will be survivable.

But if you’re going to sail close to the wind and risk the odd capsize, you have to have a system for righting the boat quickly.

Continuous integration/delivery tools are able to take all your code, assemble the product, run the tests, and ship the finished product to your servers. This makes it quick and easy to deploy a new version of your product in a single step. If you choose the right tools you will also have the ability to “roll back”. This lets you deploy a new version, watch to see if it’s buggy, and restore the previously working code if so. This makes you more free to make changes and manage any negative consequences.

What if you’re risking a more serious outage? Depending on your product, you might still take a gamble. If you’re small enough there’s nothing to stop you from contacting your key users personally in the event of an outage. If you tell the story correctly, you may even find that your early adopters are grateful to be included in the excitement of a new product.

You can annoy your users

Being small means you need to prioritise ruthlessly. Soon, you’ll find yourself prioritising the happiness of some users over others.

At Housekeep, it became clear early on that the happiness of our cleaners was our most important target. A frustrated cleaner who left the platform could in turn frustrate 20 or more customers.

At the same time, we had to build a “good-enough” online experience for our customers. As long as they were getting great cleaning, the average customer could stomach an imperfect user interface. And in our most ruthless moments, we knew they were replaceable at the cost of a bit of Google Adwords spending.

Our internal users drew the shortest straw. We built them crude and functional tools; clunky systems with bad UX. But we got away with it, partly because we were sitting next to them. They could see how hard we were working, and we could compensate for their hardships with personal attention, effective focus on their urgent needs, and the occasional box of doughnuts.

This led to an extraordinary level of tolerance among the users on our customer service and operations teams. They knew they were being heard. The problems they had with the system were our problems as well.

You can give product control to your users

While we were making our internal users deal with our clunky system, we were communicating the idea that it wouldn’t always be that way.

When new people joined the customer service team we told them that they had to come up with a product improvement during their first week. The developers would then try to ship it before their first week was done.

This was originally just a nice idea, a way to make the customer service team feel like their opinions were valued. Over time though, we were blown away by the level of engagement that we got from those users and the quality of product ideas coming out of that team.

We taught them from day one that the system they were using could be improved and it changed the way they thought. Instead of something static that they had to work with, they knew it could be whatever we as a company wanted it to be.

You can save data now and get value from it later

One of the best bits of advice I got when I was first building Housekeep sounded strange at first hearing. “Data matures like wine, while code matures like fish.”

I eventually understood it. Our application code needed to be refactored and rewritten as our product evolved, but the data we gathered in 2013 will still be useful in ten years time.

Early on, we started recording the date, time, and nature of the basic every-day operations that a customer, cleaner or staff member performed in the system — starting or finishing a job, or booking something new, or altering the schedule. It took about two days of my time to create the logging system, and from there it was just recording everything in the background.

We didn’t have any way to view or analyse all this data, it was just ticking away, adding to the datastore. Then, sometime later, it became clear that we had a treasure trove of anonymised user behaviour data. The data “matured”. The more time went on, the more the dataset grew and the value we could extract from it increased.

Survival strategies, not life strategies

I will stand behind all this advice if your team is small and your product is still emerging. I will also warn you that these ideas will become more dangerous the more you grow.

You can’t sit your developers next to your customer service team when you’ve got 50 of each. The devs will be frustrated at all the noise and not every interruption with a product idea is positive.

You can’t maintain a cavalier attitude towards breaking your own product when 10 minutes of downtime means $10,000 of lost revenue.

You can’t annoy your users when 1000s of new customers are forming their first impressions every day.

These are survival strategies, buying you time to grow big and strong enough to do things “properly”. You are not Google. But Google in 1998 was far away from the Google of today, and I guarantee you they used a few of these hacks and shortcuts to get where they are.

Thanks for reading! I’d love to hear questions or perspectives on the above from other technical cofounders, and especially from the non-technical founders who have to work with us!

‍