Do things that don’t scale
Paul Graham, the founder of Y Combinator is famously known for saying to startups do things that don’t scale. I share this same philosophy when it’s applied to new software projects. That’s not to say that I don’t care about scaling, I do, but in the overall set of priorities scaling concerns doesn’t even make it into the top 3. In this post I’ll share with you the formula that I use when starting new projects and how I arrange my development priorities so that I can get a product to market in the shortest time possible and be able to continue to improve and develop that product as it’s usage gains traction.
Introduction
My first product at Cloudapps was released in 6 weeks. There were 2 of us working on the product. I did the building, my colleague did the testing. It worked because it was simple. The Force.com platform that we built the product had many things going for it. Robust, scaleable, quick to develop on, customer onboarding quick and easy and was secure as Fort Knox. The downside was that you had to play by the rules that Salesforce build into the platform, meaning that you’re restricted on things like how many records you can fetch and how much compute resources you’re allocated, which impacts how sophisticated your solution is. I used to think of it as a bit like the regulations of a Formula 1 racing series. As a team you are free to design a car, but it has to comply with very stringent rules governing everything from the shape of the car to how much power you can generate. It really inhibits innovation and in the case of Salesforce I found that my creative efforts were primarily focussed on finding ways to work around or work with these regulations in order to build capabilities that were desirable and addressed the core offering of our product. My issue with this type of philosophy is not so much the restrictive nature of this type of development itself, but was a question that I kept on asking myself. If it’s so easy to create an application on the Force.com platform and something that produce an enterprise grade commercial application in 6 weeks with 2 semi-competent individuals, then why on earth would someone want to pay for an annual subscription for this service when they could build it themselves? Herein lies the problem and is perhaps one contributory factor behind why the native Salesforce ISV landscape has never really taken off. In the early days of the AppExchange Salesforce were promoting new entries to the market, Fairsail, Financial Force (Coda to Go) at every conference, so it wasn’t for the lack of marketing support.
To an extent I see certain parallels with what’s happening today with AI. We’ve seen the failure of the OpenAI’s vendor app store to gain traction and at the same time we’re seeing the barrier to entry of simple MVP’s being lowered as AI assisted programming and wrappers around heavyweight LLM providers make it easy to create applications which only 3 years ago would have only been possible by a few select very well funded and resourced vendors in the market. Raising the question among purchasers that has been asked every since I started my career in technology at the back end of the dot com boom - “Do we build or buy?” In my experience it’s not other competitive vendors that inhibit growth - it’s the fact that we compete with the internal tools and resources already in place. “I manage that with a Spreadsheet” problem.
Around 2018 I started work on a new product - a general purpose deep learning platform that specialised in creating bespoke models for tabular datasets. Unfortunately we couldn’t leverage Salesforce for this so we had to consider other options and settled on AWS as an infrastructure platform. The contrast with Salesforce development was stark. The rules of the tightly regulated Salesforce platform were gone as we had the freedom to use AWS’s vast range of services to develop. In many ways it was liberating and at the same time the additional responsibility of security and cost management were daunting. However I discovered that it provided the means to create a product that can have a high barrier to entry ( AI will still fairly niche in those days and required a lot of specialist knowledge to develop) and as far as I was concerned that was a good thing.
Design Choice Priorities
If I was to work on a new greenfield project firstly I would want to know that the objective was to solve a real problem. Secondly, I would want to make sure that whatever solution that was designed couldn’t be created in a couple of hours of vibe coding or using an old school Google Sheet. From there I would know prioritise the following considerations for the design:
Security
Simplicity
Capability
Cost
Scalability
Security
Yes I know it’s boring and no-one wants to do it, but the way I look at it is that if the product that we create exposes client data to unauthorised individuals then that’s a material risk and can instantly ruin the reputation of the business. Before we designed anything functional we invested time - a lot of time - in determining how to do security properly.
Simplicity
Listen to the Primeagen, Carson Gross, Dave Farley (Modern Software Design), Bob Martin - vastly different views on how to develop software, but a common theme from them is do things that are simple and iterate. With TDD advocates that comes as a natural consequence of the write the test first process. In the more liberal and less constrained approaches there is an emphasis on keep code together and not using abstractions until it’s absolutely necessary. The methods are vastly different but the objective is the same. Make software that is simple - because simple software is easy and therefore cheap to change. And if there’s one thing I have learnt about development over the last 25 years it’s that no matter how great an elegant your think your product is - it is only a matter of time before someone asks for it to be enhanced or changed in a way that you hadn’t anticipated. So you may as well be in a position where you’re ripping out 2 weeks of code instead of 2 months or 2 years of code. And this ties in to the point that Paul Graham makes. When you’re making a new product you have to get it into the hands of your user base as early as possible so that you can start gathering feedback and making data based decisions about its future roadmap. I like to think given the choice of 2 options assuming that the security implications are the same you go with the option that is the most simple and my goal is to keep the system as a whole as simple as possible for as long as possible.
Capability
We create software to solve problems. Whether that’s something to take notes during your online meetings, attribute revenue to marketing campaigns or forecast your sales. They all require capabilities to enable them to function properly. The better the capability solves the problem it is designed to address the better. Therefore given 2 options that are identical in terms of security and simplicity - I will always choose the option that will prove more capable at solving the problem
Cost
Sometimes it’s easy to get carried away and start designing real time integrations that place heavy loads on data ingestion pipelines or to trial services without fully exploring the cost to operate them. In some regards I think there’s an argument that cost should be higher up the list, and of course an element of common sense has to be applied to any feasibility study of a new product - new startups are not going to be training foundational LLMs to compete with OpenAI and so one would hope that that was already established before starting the development. This is more about making more nuanced choices during the development.
Scalability
Finally we arrive at scalability. If all things being equal all of the above are the same for 2 options then go for the one that is more scaleable.
Conclusion
Scale comes at a price which is often measured in both money and time. For a startup or a new product those are resources that are in short supply. Make secure simple solutions quickly and worry about the scaling for another day.
