24 startups in 12 months

/ home / posts / 24 startups in 12 months

March 11, 2026

How many in why?
The plan
- What is a startup
- Working smart not hard
24 startups in 12 months

How many in why?

Peter Levels has a neat blog post that pretty well details how he went from freelancing around to his first success with Nomad List. The rest of the 12 startups in 12 months, of course, is history.

Since you can go ahead and read the original posts, I’ll instead continue this one inspired by how the original post went. Which is by outlining what he describes as the “problems” that he found to have prevented his prior projects from succeeding. The twist here is I’d go and describe what I think are the ‘problems’ that have prevented me from seeing through some things of my own.

Problem one: Nailing down

If you’ve ever worked on a hackathon project right up to the submission deadline, then you know the experience. That moment when a judge asks about the project and you don’t give a cohesive pitch so much as you basically narrate what each technical component you were working on till the last minute do. Could it have been smaller and simpler in scope? Absolutely. Could it have been grander and more impressive in scope? Absolutely too.

The beauty and peril of programs is it can usually technically be simpler or technically be more complex. There goes a joke about how a recovering addict can turn down a dose of heroin after ten years clean but won’t stop to jump at implementing another static abstract singleton factory bean class in Java. An embarrassing number of projects I’ve worked on have died due to the similar disease of scope creep.

What begins as an innocuous “what if this python function did this one cool thing” becomes “what do you mean the impossible-to-read class doesn’t also do this other feature for the sake of doing that feature?” In the context of open source code or business oriented pursuits, nailing down the scope or market being actionably targeted is something I could make use of.

Problem two: Delivering the right thing

In no disrespect to Peter at all, I don’t empathize today on the point of fear of launching. If I set out in mind that I want some specific thing and I want to post it wherever I can click a share button, then I get over the jitters by doing it in a more concentrated go so I don’t let it eat away at my ego the longer it doesn’t “pick up”. Where I could certainly be improving is the design and intended user journey for my ships.

Whether it’s being more clear about a repo being something to install with a package manager versus run locally; or it’s empathetically identifying the flow in which a person would like to use some UI to solve a problem. If my goal were to be accumulating the most impressive GitHub in the world then that’s one thing. It’s another thing if my goal is to have the button people click be a payment checkout rather than starring another repo.

While I know folks who are supportive of ‘indie’ projects or who just happen to be friends, I need what I’m making to be accessible to complete strangers. An added value to dumbing down the intended interactions is they don’t need to be polite enough to spend five minutes understanding something if they could figure out in 30 seconds whether or not it solves a problem they have.

It’s knowing the audience

In both myself and others, I’ve seen the problems I described above. In the simplest of terms, I’d say it’s “knowing the audience”. If you’re writing a document for work it’s important to know whether it’s an internally facing doc that uses certain lingo or it’s a public facing article that gives a more informative picture. Likewise, if you’re making an iPhone app for young adults in the United States, it’s important to use English rather than Klingon.

From performative arts like dance or comedy to software, knowing the audience is perhaps one of the most important things to get right.

The plan

Levels was writing his post in prehistory-, sorry, pre-vibe coding times. While I can run into tier limits with Claude Code, I can still crunch out hefty applications with the right steering. Instead of doing one startup a month, I figured it could be applicable to do a startup every two weeks.

What is a startup

I’d directly quote the definitions mentioned in Level’s post however I’d like to just recite Eric Ries’:

A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty.

Different epochs or hype cycles in tech have had different categories be either popular or irrelevant; it doesn’t matter if something is cool or not if there are people who’d pay for it to exist. So if it’s SaaS or content or a physical product, it’s fair game.

Working smart not hard

Reading the debriefs from Levels’ first launches was interesting both in terms of my stated “problems” but also in terms of reaching out to news. Generalizing to post across different platforms or channels was already something I was familiar with but extending this to stuff like TechCrunch or other contemporary publications seemed immediately interesting.

Making funny things can be admittedly fun but it undoubtedly needs to be done with a careful idea on budgeting. While sending something to a cool publisher could be fun for the sake of it, it would make a world of a difference if it’s a message with a funny “advertising” video accompanied by a business rather than solely a business page or just a funny website that’s asking for an explosion in hosting costs.

Each startup will generally go through the following steps:

Identifying - what is it and who is it for?
Development - not only talking the talk but walking the walk
Distribute - share within intentional groups and audiences
Maintenance - fix bugs and apply feedback

Now, the state of the project at step three should not feel like a thing to get over with so I can get to step four and fix something or add some new irrelevant feature. Step one should include the research for what’d be done as part of step three and help eliminate any early dumb ideas that don’t have a real way to “get out there”.

In order to do maintenance well and not lose track of projects, like if custom domains and different setups are introduced, I plan to keep track of all I’m working on in a personal stack for knowledge/task tracking and vibe coded apps for repeatable processes.

Since two weeks can be a bit of an aggressive timeline for identifying and distributing, I think it could be fun to vibe code marketing apps that help continually do recon or shilling; the big important rule I’d follow is that I am ultimately pressing the Post button even if I have some assistance with finding what to reply to and what to reply with.

The thinking here being two weeks may be too short a timeline to say a startup had no time to see anything but a month is certainly too much time to be picking the sidewalk looking for gold, hence keeping the 24 in 12 approach.

Lastly, Levels is notoriously a religious supporter of PHP and it’s worked really well for him. I’ve had the chance to work with a variety of languages both for personal projects as well as professional settings; I don’t have presently have a strict opinion about what I’ll be developing these apps in. But, over a couple of these startups, I may end up finding myself with a specific set of tools I swear by.