Week 3: The Thinking Behind Uno (This is not spam)
Hey guys, it's a quick one this week. Firstly thank you to everyone who read and responded to last week’s issue. I wasn't sure about sending something so raw, but the feedback was largely positive. Thanks in particular to Matt Q, Sean G, Peter, Vinny, and Craig who all had great recommendations and started conversations off the back of it. Also to Earle who pointed out that the subject line looked like spam, hence this week’s one. Newly added subscribers can go here to understand what the mailing list is about.
There are very few updates of consequence this week, so I’m going to use it to recap on Uno — the product around which this mailing list was formed. If you’re reading this it’s likely I’ll have ranted to you at some point about Uno - hopefully this will be a little more coherent. As always, 🤓 denotes skippable nerd-talk.
The thinking behind Uno
I’ve spent 10 years building information software that runs in the browser and underpins the provision a real world service — connecting internet businesses with their customers, allowing them to streamline the provision of their service, manage these customers centrally, and scale super-linearly. Their stack normally consists of public facing product(s) through which customers interact, relational database(s) in which information is stored, and internal product(s) used by staff to collaborate, liaise and plan around them. I’d estimate that over 50% of all successful “tech” businesses follow this model or a variation - airbnb & uber being recent examples.
The way that we currently build this type of software goes something like:
Secure funding.
Find and hire experienced, expensive computer programmers and designers.
Design and configure the complex systems that underpin the software: languages, libraries, frameworks, production environment, continuous integration, software development lifecycle, git flow, security practices. The list goes on…
Set up collaboration and handoff mechanisms between PMs, designers and developers.
Write the code to create the features, most of which are rudimentary.
Repeat and refine 1 - 5.
I’m convinced that the way we currently build this class of software is obscenely inefficient. I’m convinced that there are enough similarities in the patterns and abstractions within this type of software that we should be able to build it largely without web software engineers - that normal people now possess the conceptual vocabulary (relational databases, spreadsheets, design systems, components) and what’s missing is the right tooling. And I’m convinced that the market for this tooling is much larger than just internet startups, as small businesses of all shapes and sizes increasingly begin to use cloud software to connect with their customers and manage their business. In the same way that Shopify obsolesced developers for e-commerce, and Squarespace, Wix and Webflow obsolesced developers for websites, I want to obsolesce developers for this type of software.
And that’s the thinking behind Uno.
I’m going to leave it top-level for now, as I know I’ll be refining it over the coming months, and creating decks and articles that go into more detail.
Links & Reading this week
Daniel Gross wrote a well-timed piece (“When ‘Grow your revenue’ is wrong”) which expands on the ideas I touched on in week one and week two outlining how important it is to take your time when building something ambitious.
🤓The Web as a GUI toolkit - interesting take which states: 1. The web was created as a typesetting system, 2. That inadvertently made it work well as a GUI toolkit, and 3. Separately it’s also great because it’s given everyone a programmable environment. Personally I agree with (1) and (3) but not (2).
Why are we so bad at software engineering - an insider’s perspective written for outsiders on why software engineering is a mess, featuring this xkcd comic.
Corrections from last week’s mail
🤓 Javascript is a procedural, not functional language.
I left out some links in the Indiehackers section: Guy at $22k MRR on part time project, product similar to Editmode at $27k MRR, all projects making over $10k MRR.
Recap of mails so far
Special request by Brian to include the snow monkeys we visited in Nagano.
That’s all ‘til next week! Thanks for reading!