The downside of “Doing things that don’t scale”

I once read an essay from Paul Graham that was, in his typical way of finding counter-intuitive yet spot-on analogies, comparing startups with babies.

« Inexperienced founders unconsciously judge larval startups by the standards of established ones. They’re like someone looking at a newborn baby and concluding “there’s no way this tiny creature could ever accomplish anything.” »

When I co-founded my previous startup, we did not get product market fit before a while. In fact it remained at this baby stage for quite a long time before it finally took off. All this time, we had avoided premature scaling at all cost, following the “Do things that don’t scale” principle to the letter. Our development decisions were taken to be just right for the current state of the business. We thought our operations would end up scaling just by adding more people when the time would come.

Once, Our Startup Was A Baby

Customers finally started piling up after months of trying with different acquisition channels. And the bit of traction we got hit us like a truck. Instantly we ended up working with processes that were never thought out to work for more than a customer here and there. Support tickets, Customer requests for features and data instantly piled up next to the customer pile. That looked bad.

We decided that building proper administration tools was the only way to keep our cohesion in front of this spike of work, and looked at the technologies that were available at the time.

It seemed obvious that we would have to build these tools ourselves: there was just no solution on the market that would allow us to manipulate your data the way we needed and be flexible enough. Building it on Bootstrap seemed like a no-brainer: We were already using the venerable framework for our front end and there would be little learning curve for our new recruits.

If only we knew that the mistake did not reside in the word “Bootstrap”, but in the word “Build”.

And Suddenly, It Had Become A Teenager

We reached at fast pace 300 merchant accounts on our platform and did not even take time to celebrate passing 100’000 App users. Our day-to-day was a very ordinary version of what happens at every startup: our hair was on fire 🔥. Our product team was submerged by the task of scaling and developing the product at the same time 🌊. Having been ambitious, we had been guilty of selling features that were not ready yet. Clients wanted result.

We had invested less time in our back-office to free development effort for the product, which had made the back-office really lag behind the product. Immediately, it meant a lot more work for our developers, that had to manually run many support tasks themselves.

Before we knew it, we had fallen in a catch-22. Investing time in our Admin Panel would cost us precious developer time we needed in support and to deliver the promised features. But not investing time in our Admin Panel was costing us the exact same thing! In the meantime our operations had become slow, uncomfortable and inefficient, adding about one more full time position to a team of 6!

It became apparent that these problems were faced not just by us, but by all startups and web-based companies that are growing fast.

What We’ve Built To Address This Catch-22

I moved on to join efforts this year with Forest Admin (www.forestadmin.com), a Paris based startup that decided to solve exactly this problem, that I had experienced first hand.

The team had come to the same conclusions. They had reviewed and identified the weaknesses and bottlenecks of in-house-built Admins. They were building a modular Admin-as-a-Service, that plugs into any App and that would leverage the synergies between all admins. They started with the 5 things in particular that were costing a lot of time to everyone:

1- The Juggle With 2 Themes/Layouts

Self-made admins almost always require to deal with at least 2 different themes/layouts, CSS assets and javascript: one for the customer-facing product and a second one for the admin. Basically like two products at the same time. So we built a new framework specially for the admin, that would be fully drag-and-drop customizable, squarespace-like, and automatically plug-in the data it needs from the App. It turns out it works surprisingly well. Forest manages to completely take out the need to build a new Admin interface, letting developers fully focus on their product. First thing off the list! ➡️🚪

2- New Feature = New Feature + Administration Panel

Every time we rolled out a feature, we needed to go at it a second time and implement, in mirror of the product, the Admin CRUD for the newly added tables and columns in the database. Double the work, every time. It doesn’t seem very DRY, does it? So we purely removed the need to re-implement CRUD, the same way we removed the need to deal with 2 layouts: with the drag-and-droppable interface we had developed. Forest was now capable of automatically building a complete Admin interface, with full App data manipulation. The second recurring manual process was off the list.

3- API Integrations Here, There, And Here Again

It’s mind-blowing to think about how many different SaaS we can rely on today just for the company to operate normally. You probably use several of these: Stripe, Intercom, MixPanel, Slack, MailChimp, ZenDesk, … And we did too. Since we often integrated their APIs to our Admin Panel, and since API calls are all the same, its was just a perfect use case for our drag-and-droppable interface. So we went on and implemented it. This allows Forest to dynamically connect back-ends without writing code.

Implementing API calls for the back-office and operations: never again!

4- Developer, Ops Guy, Intern, And Sensible Data Altogether ⛔️

Admin Team permissions were never at the top of the priority list. We just learned to live with the fear that anyone we hired, intern or else could access billing information and make big mistakes with other settings. Guess what? We took care of that in Forest too. Two-step authentication and team permissions: off the list!

5- Admin Down = No Sales + 1 Billion Support Tickets Awaiting

I remember how we were making jokes about how bad it would be to have our Admin down for a day at my previous Startup. Having our Admin down would have meant a catastrophe for our partner merchants, a sudden stop in our sales and fulfilments, and a serious hit to our reputation. Fully automate-testing and having a back-up server for our back-office seems extreme, yet it’s the only way to insure 100% reliability at scale. As a startup we could never justify to invest the time to do that, and resorted to live with this fear and joke about it. But Forest changed everything: working on a product that is an Admin as a service allows to invest the time to provide this safety to everyone using it.

These were just a start. In fact, it was only our first iteration in our mission to make DIY admin panels -on Bootstrap or not- a thing of the past. Since then, we have found many more synergies in administration tools that we’ve added to our product, and we are now doubling down our efforts to boost the operations of 50+ employees companies.

Our users would hate to feel locked or limited for their Admin Panel and we would feel the same, so we released our plugins in Open Source, as decided in our No-Pricing Manifesto (“Learning with you, not at your expense”) that we published some time ago.

If you had similar experiences with your hair on 🔥, don’t hesitate to share them with our post; we’d love to hear about them! If you try out Forest and you like it, we would love you to give us your feedback, good or bad.

We hope our contribution will make your coding happier and your life easier!

🚀 Now What?

• Thanks for reading! 🎆
• Your comments are welcome! 👏🏻
• If you want, subscribe to my blog for news and guest perspectives about product development.