#business-general

You don’t need the cloud

Diederik • @jdvhouten • • Part of Day 11

Putting your web service on the cloud is the default choice nowadays. Who in their right mind still uses dedicated machines these days?

Well, us. We do! We’ve used dedicated machines for our startups since 2006. AWS back then was kind of expensive and slow, and we were broke. We used low-budget dedicated machines out of necessity. Fast forward a decade and a half and we still use dedicated machines for almost everything[1], even though the cloud has gotten a lot cheaper and cost is not an issue anymore.

The reason is simple. Dedicated machines offer unparalleled performance and are rock solid.

This is the pricing table of hetzner.com, a popular German hosting provider.

You can upgrade the NIC if you want a 10 gigabyte uplink. You can set up your own private network if you want. You get a free firewall, a remote reboot console, IPv6 IPs, ECC ram, plenty of bandwidth, separate storage for backups. Pretty much everything you can think of.

You can serve an unbelievable amount of traffic with a single dedicated machine with a few hundred gigabytes of ram and a dozen cores running at 5ghz. Most web apps don’t even do that much. It’s JSON in and JSON out. Most traffic will hit a handful of endpoints that makes optimization/caching easy.

You can use Cloudflare to serve all your static content quickly. If you want, you can proxy all your backend traffic through Cloudflare as well.

You can use simple linux tools for backups. We think rdiff-backup is incredible. But there are plenty of alternatives. Doesn’t even take long to set up.

What does AWS have to offer?

  • S3. Unless you store a massive amount of data you don’t need it. And if you want to get it out, be prepared to shell out for egress fees.
  • Route53. It’s fine, but Cloudflare offers DNS hosting as well.
  • Identity management. You don’t need it.
  • RDS. It’s slow and super expensive. I don’t want to worry about one-off queries or migrations. If you use only 5% of your server capacity you can afford to do inefficient things at times.
  • Billing surprises. Today I read another one of those. I don’t want to worry about this stuff.
  • Lambda? Beanstalk? Glacier? EBS? What even is all this stuff.

If you’re a startup you want to focus on your product, and all this cloud tech is just a distraction. AWS is for big companies with a lot of turnover that can’t run their own machines. Unless your startup needs so much compute or storage that running your own dedicated machines becomes unmanageable I think you should just say “no” to all of it.

[1] This blog runs on the cloud but that’s because WordPress is a security nightmare and a cloud VM is the easiest way to sandbox it. Ironic, I know.

Always build the hard part first

Diederik • @jdvhouten • • Part of Day 11

As a kid I would always work on one project or another, but I would often postpone working on the hard bit. I would the easy and fun stuff first, and it felt like making great progress. If I wanted to make a video game I would start with the game engine and interface but never get around to making the actual game mechanics or levels. If I wanted to make a web app I would try five different tech stacks in order to find the “best” one. I would build user registration and password reset systems but ignore the core functionality. By the time I got to the important part I would figure out that either the concept didn’t work or that I wasn’t able to build it. Abandon project. Repeat.

It took me an embarrassingly long time to learn but eventually the lesson stuck. Build. The. Hard. Part. First. No exceptions. In other contexts this is known as “unknown unknowns“, a concept popularized by Donald Rumsfeld. Your first priority is to work on the hard parts where you don’t know what kind of problems you’ll encounter (unknown) and you don’t know what it will take to address them (unknown). Then focus on the known unknowns. Save the rest for last.

We’re making a prosumer web app. For apps like these there are two types of hard problems: technical and user experience.

Tech challenges

Challenges are technically hard when you’re not sure if you can make something work at all, or work reliably, or fast enough. Or when you have no idea how long it will take.

For these technical challenges you want to build small prototypes. If you can figure out in a short time (days, a week) what it will take to find a good solution you want to do this early on. Way early.

We’re already making tech prototypes and we haven’t even figured out yet what the core functionality of our app will be. This might strike you as backward, but it’s entirely intentional. You can’t decide what the app should be like if you don’t know what you can realistically build in the time you have.

You can never build the ultimate version of your app. That would take years. If you’re lucky you can make 5%. And your app, despite being only 5% of what you want it to be, should still provide real value to the user and present a clear vision of where it’s headed. Technical prototypes help you figure out what has to get left on the cutting board. Tech prototypes turn unknown unknowns into known unknowns.

UX challenges

It’s easy to imagine better products. We all get annoyed with apps that don’t work right. Or are slow. Or that don’t have features we consider essential. Actually making an app that is great? Not that easy. It’s a cliché but true: everything is a trade-off. Fixing bugs and making software fast takes time that could otherwise be invested in features. It’s still true when you don’t take time into consideration because you can’t make software better by just piling on more features.

That’s the real difficulty of User Interaction (UX) design. If you want to make software that is intuitive to use you can only put a handful of features front-and-center. You can hide some extra functionality in panels or settings pages, but that doesn’t change the fact that you have to direct the user’s attention somewhere. If you put the right features front and center that will make your app cohesive and intuitive, and if you get it wrong your app will be mediocre at best. UX problems are known unknowns. You know you have to solve them and they won’t blindside you like technical issues do.

UI sketches and thinking will get you only so far. At some point you have to build a primitive version of your app to figure out if the concept works at all. Innovation is great, but you don’t want to be different for the sake of being different. You want to make something that’s original and also — at least for some people — much better than anything else out there. The sooner you know if you’re on the right track the better. The only good design is redesign[1].

Leave the easy parts for last

When the core of your app is done and you’re happy with it you can go back and work on the long tail of easy parts, the known knowns. By this time you should be super excited that your app is finally coming together and you’ll have no difficulty hammering out mundane stuff like billing, user registration, and a settings page.

Conclusion

Build small prototypes before committing to a specific vision. Make something you can interact with so you can feel if you’re on the right track.

Finally, keep an open mind. It’s possible (perhaps even likely) that your original approach is just worse. Sometimes you can pivot into something that works. In most cases you have to face reality and cut your losses altogether. It’s rough to abandon what you worked on for months or a year but it’s the price you pay for trying to innovate.

[1] These UX challenges apply mostly to consumer products. For B2B software customers are willing to put up with a broken and poorly designed app if it addresses a big pain point for them or makes them money. The quality bar for consumer apps is a lot higher.

Skills you need to bootstrap a SaaS startup

Diederik • @jdvhouten • • Part of Day 5

When you’re a technical founder you have to do everything yourself. These are the skills we had to learn:

  • Product sense and taste. No shortcuts here, this is just a matter of experience. To get better product sense think hard about the products you use and ask yourself what makes them good or bad. Which features do they have and what set of features make sense to combine in a single product. Related is interaction design. This is the skill of designing user interfaces where the buttons and toggles are where people expect them.
  • Decent software engineering skills. You’ve got to make a prototype that people can recognize has the potential to be great. This means you need to know Javascript, and CSS at a minimum. You can use a frontend stack like TypeScript, Angular, or React if you really want to, but it isn’t necessary. How much frontend code does your webapp need for an MVP? You can get a lot of functionality from a few thousand lines of plain Javascript. Frontend Javascript frameworks mainly exist to simplify working with many people in a mature code base, which doesn’t apply when you work on an MVP or prototype. You don’t need to mess with CSS compressors either at this stage. It just doesn’t matter, and you want to move fast.
  • For the servers you need to know a backend language or two. It doesn’t matter whether it’s Python, golang, java or anything else. They’re all pretty much equivalent. Only the quantity and quality of the libraries you have at your disposal makes a big difference. Webapps are (or can be!) pretty simple at the backend because you have full control over the stack and that makes for easy debugging. The common wisdom is that you just stick with whatever backend stack you know best, and I agree.
  • Server admin skills. To run a web service you basically want to understand the entire tech stack. Databases, TCP/IP, firewalls/routing, http, SSL, etc. This stuff isn’t especially hard, there is just a lot to know. If your app stops working in the middle of the night you want to be able to diagnose it quickly.
  • Security. It takes a ton of effort to make web apps secure because everything is a potential security hole. Everything from authentication tokens, to cross-site scripting, to weak cyphers, to SQL injection, to broken firewall rules, to denial of service issues, header splitting, remote includes, and the list goes on. Extreme paranoia is warranted. No product is perfect, but if you’re going to store sensitive customer data you have a moral responsibility to really know what you’re doing in terms of web security. You must never cut corners here.
  • Visual/graphics design. It’s hard to stand out when your app doesn’t look good. You might be tempted to lean on templates or pre-made themes, but if at all possible create your own style from scratch. People will judge your app on how it looks so you better learn how. Even when you’re not a natural (and we’re not) you can make something that’s pretty nice looking if you follow the “rules” of good visual design.
  • Type words good. You have to communicate to people what your startup does and what problem it solves. If you can’t explain in simple words what you’re doing you aren’t ready to build an MVP. Writing is a skill like any other and you’ll get better with practice. Don’t worry about sounding serious or business-like, worry about getting your point across.
  • Sales skills are optional. Just use plain language to describe what the benefits are of your software and then “ask for the sale”. Techies like us think asking for a sale is scary or morally wrong, but that’s something you’ll have to let go of. If you’re great at software you’re unlikely to also be a smooth salesperson, and that’s OK. Let non-technical founders do the sales-focused startups.
  • Business sense is optional if you simply write software and charge money for it. You can google the rest, when you need to. Your startup isn’t going to fail because you can’t figure out how to incorporate or how to calculate VAT correctly. The business stuff can be tedious and aggravating at times, but it’s not hard.
  • You should know basic finance. It’s not hard. You should understand the formal basics like a balance sheet and cash flow statement as well as the concepts specific for web businesses. Look up what customer churn is, acquisition cost per user, customer lifetime value, and stuff like that.
  • You do need a good amount of common sense. This seems almost unfair to include, because it can mean anything. But many startups fail because founders make boneheaded unforced mistakes. Common sense means figuring out what matters and what doesn’t, and then doing only the stuff that matters.
  • You need optimism, pragmatism, and persistence. Optimism because startups are hard even when you have a cheerful disposition. Pragmatism will keep you grounded. Persistence you need because startups are highly random. Like everything else on this list, you can work on these skills.
  • And of course you have to be resilient. People will tell you how your startup idea is dumb, or that nobody will pay for it, or that it’s a toy, or that it’s too risky, or that you should raise money. The list is endless and we’ve heard it all. Thankfully, it doesn’t matter what the naysayers believe.
  • You don’t need a network or Twitter followers or investors or anything like that. If you have an internet presence it might help but we’ve been doing SaaS products for over a decade in complete obscurity. It’s fine. Social media skills are optional.

Okay, this admittedly turned into a long list. But many people already have all the technical skills already and only need to figure the basics of the nontechnical side. Github is overflowing with cool projects made by dedicated programmers who really wish they could work on their projects full-time. But they can’t, because they don’t take that extra step of turning their project into a startup. A main goal of 80daystartup is to show people who already have the technical skills — by showing them in real time — that building a cool product along with a dash of marketing is all it takes.

Our hope is that people, through the course of this adventure (or incredible journey) will see how bootstrapped startups are perfectly realistic alternative to VC funded startups with hockey stick growth trajectories. Bootstrapped startups can also grow quickly and become massively profitable. Besides, when you own 100% of your business (or 50/33 percent if you have co-founders) you don’t need to become a massively successful outlier.

This somewhat reflective post wraps up our first week for 80daystartup. We figured out what we’re going to make and we’ve got some rough design sketches so far. Next week we’ll try to come up with a good minimal feature set that we think can make for a compelling MVP. Then we’ll start prototyping individual features so we have something tangible to interact with. But let’s not get ahead of ourselves. One week down, fifteen more to go!

The initial stages of a SaaS product

Diederik • @jdvhouten • • Part of Day 4

These are the phases you’ll typically go through when you start a SaaS product:

  • Idea phase. Here you try to figure out if there is a hypothetical market for your idea. What kind price you can charge and how you will reach your audience. If possible, explore multiple ideas and let them marinate. Don’t rush this stage. At this point anything is still in play. But the decisions you make here will affect what kind of customers you’ll have, what kind of technical challenges you’ll work on, whether you’ll make money, and everything else. Any business has fun and not-so-fun parts, so choose wisely! Owning a business that operates smoothly and profitably is a lot of fun, and you’re unlikely to get bored. By contrast, working on a product you’re passionate about that has no functional business model is painful and you’ll start to doubt yourself sooner or later.

    If you’re a techy (like me) you want to choose a startup idea that has a relatively straightforward customer base and business model. That way you can succeed if you have an excellent product but mediocre marketing.
  • Prototype phase. Good taste and good design sense matters. If your product looks good users will assume it’s is a good product, and you’ll get the benefit of the doubt when something doesn’t work right. If your product looks sloppy you’re going to lose people who would otherwise be interested. Prototypes are by their very nature flawed, but you don’t want to make an app only a founder could love.

    You might think you can save time by using cookie-cutter CSS templates/frameworks, but these frameworks make your product look bland. Your product should be visually distinctive. People are far more willing to try products that look different, and this also makes you more memorable. The world is a diverse place and people have different tastes. By being different you’re going to alienate some people and attract others. That doesn’t sound great, but the alternative is being bland, and then you won’t have any enthusiastic users. Big businesses can afford to be bland, startups cannot.

    The press also likes to cover things that look new. It’s tech fashion, basically. Design styles go in cycles. Do products use a lot of whitespace, or very little? Skeuomorphic design or Swedish minimalism? Muted pastels or saturated colors? When a startup becomes super popular you’ll see many other startups copy their visual style. It’s pretty funny when you notice it happening. Of course, there are no right and wrong answers in fashion. And what looks fresh in one year can look tired two years later. A sloppy and amateurish look will do you no favors.

    Your product should have very clearly defined core functionality. Businesses with money to burn can afford to have their product be a confusing mess. You can’t. Your users will simply move on if they don’t “get it”. And you can’t blame them. In this prototype phase it’s your job to figure out if your innovations actually make sense. And because you’re going to rewrite these prototypes anyway you can cut corners if you have to. In addition, you can experiment with the software architecture of your program. Changing your mind in this stage is cheap, but refactoring a live service with millions of users is painful. The prep you do here will pay off handsomely.

    In this stage you figure out the identity of your product. How you interact with it. What it feels like. What it does.
  • MVP phase. Here you build the real thing. It has to be good enough so people can actually use and derive value from your product. The goal isn’t perfection in this stage, but you don’t want launch anything half-assed. As Wim wrote earlier today, you want the core functionality, and nothing else.

    Everything that can reasonably be postponed to after the launch you postpone, even those features that you know people will be asking for from day one. The goal of the MVP is to get good user feedback. The most important thing is whether you believe the product is any good, but if you’re the only person on the planet who believes it is then you’re in trouble.

    What you really look for in this stage are people who think your MVP is great. It doesn’t matter how many people hate it, or don’t get it, or are indifferent. None of those people will become customers anyway. You only need a handful of passionate users at this stage. Talk to them and judge if you can actually turn your MVP into a business. If you can’t find any passionate users, then maybe your idea wasn’t so great after all. Or maybe your execution sucked. This is really the critical junction. At this point you can still walk away without having invested too much. Delete everything and go build something else. If you go ahead with the commercial launch before you have clear evidence that people need what you’ve made you risk running a zombie startup: one that’s neither dead or alive. This sucks because you might thread water for years. Barely surviving, but not going anywhere. Don’t let this happen to you. But if you proceed and turn this into a real business, then you also have to accept all the responsibilities that come with it. Onwards!
  • Commercial launch. Whoo-hoo! Your first paying customers. Hopefully, you didn’t have any trouble converting your beta users to customers. Now you have to fix in a hurry all the shortcuts you took while building the MVP. And you have to figure out billing, invoicing, refunds, customer support, backups, failover, GDPR compliance and everything else. This stage is schleppy but the excitement of growing your tiny business will help you power through it.
  • Scale. Don’t get distracted. Focus on your product and the customer. Setting the right priorities is everything. Learn to say “no” a lot.

On competition and disruption

Diederik • @jdvhouten • • Part of Day 3

Wim just wrote about what our product is going to be. In this post I’m going describe how our task/planning IDE relates to other products in the space.

State of the market

To-do/planning apps can be roughly categorized like this:

1) Pen & paper. Making plans on paper is pretty fantastic, provided you’re meeting in person. After the meeting you have to manually transfer your paper plans to a calendar. That’s a bummer. And then every person has to keep a separate todo list for their daily responsibilities. And then you need regular meetings to coordinate the info from the notepads on each person’s desk. Pen and paper might work if you’re by yourself, but it doesn’t cut it when you work in a team.

2) Glorified shopping-list apps. Apple’s Reminders app fits in this category. Apps like these are only suited for casual use. They don’t allow for any higher level planning. Collaborating with multiple people doesn’t really work. Creative work can be chaotic. You want to be able to type in free form, but you can’t. And modifying or reorganizing tasks is tedious.

3) Kanban boards like Trello. It’s a pretty decent solution for planning in a team. It’s like moving post-its on a digital whiteboard. Trello is a good product but Kanban boards address maybe 20% of the problem.

4) Single user (desktop) apps like Things (for casual use) and Org-Mode (for power-users). No matter how great these apps are, in 2022 people want software that’s suitable for remote teams.

5) Enterprise team scheduling apps like Asana. Products like these have decided to appeal to large businesses by shoehorning in as much features as possible. If you add everything and the kitchen sink a product will look great in a comparison table or during a PowerPoint presentation. But who wants to use bloated and slow products like that? Not us.

In 2020 people download 1.7 billion task/productivity/do-apps in the USA. It’s a huge and growing market and people are clearly clamoring for better software. This is matched by our personal experience. We’ve tried a bunch of todo and planning apps over the years and none of them really work the way that feels natural to us.

We think a major product category in this space is missing: the IDE. A task/planning IDE that is for teams, primarily text based, friendly to power-users, and that can be used for high level planning down to disorganized note-taking. None of the popular products try to solve this problem.

Because we’re going to be the first product (to our knowledge) in this segment it remains to be seen if there is a sizable market for it. For the time being we’re delusionallycautiously optimistic.

Market disruptors

IRC never got into the mainstream. Not user-friendly enough. Difficult to share files. A few products like HipChat and Campfire tried to bring IRC-like chat to the mainstream, but ultimately failed. The user experience as a whole wasn’t very compelling. Then Slack set the world on fire.

The story of Spotify is similar. Many people predicted that online music streaming was going to be huge and many startups tried to make the killer app. Spotify was the only one where you could click play on any song and immediately hear music and enjoyed explosive growth as a consequence[1].

GMail was the first email client with search that worked, spam filters that worked, and you could keep a staggering (at the time) 1 gigabyte worth of emails in your account. GMail has stagnated for a decade now but back in the day it was transformative.

Slack, Spotify and GMail all completely transformed their markets by making a product where the –core functionality– was leagues ahead of everything else out there. When you nail the core experience your app can be deficient in other areas. Your users will understand and forgive, provided the core experience makes up for it.

When a segment of the software market feels stagnant it’s because the apps have converged on a local maximum. The different players try to keep ahead of the others by piling on features, but this backfires. By copying each other the products end up in the same spot.

We believe that the task/planning apps out there are stuck in local maxima, and are ready to be disrupted. That’s not to say we’re going to be the ones to do it. We can’t see the future, and our hunches are wrong more often than not. Nonetheless, our concept is solid. Now we have to create some prototypes to discover what feels right and what doesn’t.

[1] The real story is more complicated. Spotify also has to get all the critical licencing deals done and, like many startups, almost died multiple times. However, Spotify’s strong initial growth can be attributed to technical excellence of the product.

What are we going to build: The Idea

Wim • @wcools • • Part of Day 3

Update @ Day 21: the landing page is now live! Check Thymer.com for more details.

It’s day 3 of 80, and the decision on what to build as a startup in the remaining 77 days has been made! As we summarized here, it will be a web app (SaaS), and it’s going to be a… brace yourselves… to-do list app. Haha, yes, well, kinda.

Building apps for tasks and notes sound like a cliché at this point. The last internet census counted 68,482 to-do apps. It’s even become the “Hello World” example for web framework tutorials. So perhaps it’s only fitting to build this as the ultimate example of how to build a startup! We’re planning to build a real product though. And as we outlined yesterday, we only think an idea works if it has a “first”. So we want do try a new approach in this category:

We’re going to build an editor/IDE1. Except it’s a text editor specifically designed for tasks, planning, and thoughts; for makers to manage creative work.

Using an editor interface for managing tasks and planning feels like a much more logical fit to us than the existing categories, the classic to-do lists and kanban boards.

The most obvious symptom of the problem with the existing apps to us is a “todo.txt” on our hard drive. We know we’re not the only ones who keep falling back to just jotting down notes in a text file or (virtual) stickies. With text, you can write down tasks or thoughts as fast as you can type, indent as much you want, collapse/expand sections, select, copy/paste or move a bunch of text somewhere else, add whitespace… format it any way you like. All these features are essential for organizing thoughts.

Having to decide what needs to be a project vs a task vs a subtask when you’re just typing out thoughts, having to click buttons, using an interface that gets slow when you enter more than a 100 items… it’s just too much friction and disrupts the creative flow. So it’s great to have all these fancy apps, but in the end, we end up with a todo.txt, again. And although a text file works, there’s no way to visually organize things, add any structure or links, collaborate in teams, drag things around, filter or schedule things. It’s just plain text, after all. So we can never find anything back and after a while declare text file bankruptcy and start over.

We want to have the best of both worlds. And we think that looks like an IDE. When you think about it, IDEs have similar features you need in a todo app built-in: things like syntax highlighting, collapsing indented blocks, keyboard command palettes, and plugins. Instead, our “IDE” will be for anything related to organizing creative work: commands, auto-complete and highlighting for things like dates and priorities. With support for scheduling, references, split-panel views, and being able to drag things around. And like an IDE, “hack-ability” in terms of plugins is a big thing too, because good tools should adapt to how you like to work.

We could talk a lot more about other cool properties this kind of system would have but that’s the idea at its core.

In the next post we’ll recap why we think this might work as a startup to build in 80 days.

[1] For non-coders: Integrated Development Environment, fast and powerful editors and related tools for programmers

Honing in on an app idea

Diederik • @jdvhouten • • Part of Day 3

We’ve been brainstorming in the past couple of days about what we’re going to make.

So far we’ve determined that:

  • we want to build a web app, because we need the friction to sign up to be as low as possible
  • we want to make something we can personally get excited about
  • we’ve also decided that we want to make something small in scope (only 80 days!), that is cheap to operate (no budget)
  • we’ll make at least one version of the product free (100% free, no ads) in order to get as much word of mouth advertising as possible
  • we ideally want some kind of subscription service (SaaS) for small business. We’ll write about the economics of SaaS businesses later
  • and we want to make something that’s unique enough that people can get genuinely excited about it
  • our app has to find a niche in an established market with plenty of competitors
  • we want to tackle some fun technical challenges. This will be harder for us in the short term (because it might turn out that people don’t care about our app at all), but it should work in our advantage in the long term (it will set us apart from the competition)
  • this means the core functionality has to be unique. If you only have 80 days you don’t want to waste it replicating common functionality, except for the bare minimum like account sign-up, login, and subscription logic.
  • we want to make something that can rapidly grow to millions of active users
  • we want to make something that has broad appeal among regular people (“horizontal” in business speak, as opposed to “vertical” apps that target a specific industry or profession).

This narrows down the universe of app ideas tremendously. Right now, we can only think of a few potential products that meet all these criteria. And that’s okay, because we only need one!

Startups are all about constraints

Diederik • @jdvhouten • • Part of Day 2

You can start a web startup with the money you find between your couch cushions, but good luck trying to start a rocket company that way. Web startups are unique in that they require no upfront investment whatsoever. For all of history you needed to have money to make money. No shortage of corny expressions saying so. But not anymore! The internet is the great equalizer. And the internet is still growing rapidly, which means there is an abundance of opportunity. That’s pretty sweet, too.

However, even web startups face significant constraints. But that’s alright. It just means you have to be a little creative.

Constraint 1: Web Tech

You have to use Javascript and CSS which greatly limits what you can create. Essentially you’re restricted to using a tiny fraction of the computing power on the device and you’re locked into a browser sandbox that is crufty and constantly shifting under your feet. Code you write today might stop working tomorrow or next year, but almost certainly by the next decade. The more you push at the boundaries of what’s possible within the constraints of a browser the more likely your code is to suddenly stop working on one of the major web browsers. Windows and Linux utilities written 20 years ago still run fine on modern machines. On the web everything breaks for no reason. If the web is so bad, then why build a web app at all? Because the web takes care of the distribution problem.

I suppose the silver lining is that many of the web products out there that you’ll end up competing with will be barely functional. The quality bar you have to meet is low on the web, but despite that we still intend to make something that’s rock solid.

Constraint 2: Time

We’re giving ourselves 80 days. That’s not much, when you take into account we also want to document what we do. We risk running out of time if we waste even a couple of weeks going into technical dead ends. We have to ruthlessly cut all non-essential functionality. We have to say no to almost all the thing we want to include. After we cut nearly everything will we be left with something that’s not just a pointless toy? It’s a fine line to walk. If we don’t get the core set of features right nobody will get excited about our product. But if we build too much we’ll have to rush at the expense of quality. Tomorrow we’ll create a rough timeline of how we think we should allocate our 80 days. Err, I mean, 77!

Constraint 3: Audience

Even if you have the technical skills to make something, and the time in which to do it, you still won’t get anywhere if you don’t have a way of reaching your target market. We’re no good at marketing, and we don’t particularly enjoy it. Which means we can only build products that can –at least in part– sell themselves by word of mouth. In addition, we want to make something that we can directly drop people into so they can play with it. The product must largely sell itself, because we’re not going to. This means we’ll have to put a lot of our attention on onboarding. We have to make a great first impression and our app has to feel fresh. When the traffic to your website is only a trickle you have to convert a large percentage of your visitors. We’ll have to compensate for our lack of marketing skills by making a sticky app with good curb appeal. This means we can’t build anything that confuses people or that is too weird.

Constraint 4: Money

I’m adding this constraint for completeness, and because money and time are interchangeable. We could self-fund several years of development before launching anything. That way we could do exploratory programming and we could tackle much more difficult technical challenges. But we’re not giving ourselves a budget here, except for the bare minimum. We’ll need some server space. A MacBook maybe. We won’t spend anything that would put a big dent in your savings. There is no money for ads. We’re not flying to conferences. We’re sticking to the basics.

Our goal with #80daystartup is to show how you can bootstrap from nothing. No money, too little time, no audience. You just have to be very mindful of the constraints you face. Our goals here are intentionally modest, in an effort to show that starting a very simple startup is still totally worthwhile. And if all goes to plan we can show that something that starts as a very modest startup can easily pivot and grow into something far more ambitious. But that’s something for a later update :).

Bad Ideas: What Not To Build

Wim • @wcools • • Part of Day 2

Much has been written about picking startup ideas. Although a good idea won’t be a guarantee for success, of course we want to avoid picking a bad idea which sets us up for failure even before we start.

As part of picking an idea is identifying bad ones, we wrote down some of the points we check our ideas against to see if we’re not too quick to jump onto something which isn’t a good fit. Not everyone will have the same criteria, and in our case it’s mostly about bootstrapped software business, but here goes:

1. It’s not super relevant for us

If we can’t even convince ourselves we’d really want to use this, how would we convince others? How do we come up with improvements and novel solutions, if it’s a problem we don’t want to solve for ourselves? How can we find and interact with our audience if they’re nothing like us?

Just as important, how are we going to stay motivated and care enough to make it a success when inevitably there will be some roadblocks along the way. Everything feels like an uphill battle if you don’t think an idea is really interesting, matters enough, and is fun to work on. When an idea does fit, working on it feels like going on autopilot.

That rules out going for that “I have an amazing idea!” you read about somewhere else.

2. It doesn’t allow us to run the business we want

Besides the problem space itself, the idea must support running the type of business we want. Can we use the skills we enjoy using to make a difference in this space? What other aspects of running a business do we find important (for example, being able to work remotely, not having to raise capital, and so on).

Likewise, what are things we really hate doing? There are always tasks that aren’t fun, but if the success will depend on us primarily doing exactly those, we’ll likely not do them on autopilot as we should and risk not moving forward fast enough. It’s better to be honest about this beforehand, as now is the time to pick an idea which is fun to work on by design. No use in trying to launch an idea for the enterprise market when you have no interest in sales.

3. There is no part of the product that’s a “first”

Not building something that’s original would violate #1 for us. But even if you enjoy building a “me-too” product, the internet will be too saturated to care. Some things might have worked five years ago but not anymore. It’s easier to be first (some things even just work once).

No product is 100% original in every aspect of course. In fact, if the category of product doesn’t exist at all yet, that’s often a red flag. But something about it needs to really stand out in a fundamental way. Think about how fans of this new idea’s approach would never want to go back. And how your product did it first.

Just like the product, the marketing (or anything related, like business model) needs a first, too. It’s not the web of 20 years ago anymore. There’s more content competing for attention than ever. Ads are dead (prohibitively expensive for many bootstrapped businesses). Established Marketplaces (like App Store or G Suite) are saturated. Provided you execute well, the chances someone buys from a competitor is not because their product is better, it’s because they don’t know you.

It’s more important than ever to stand out, but there are many ways to do so. For example, the first community around X, the first SaaS version of X, the first privacy-first version of X, the first open source version of X, the first freemium version of X, the first premium version of X, the first to use a channel for X. Everyone needs a thing.

4. We don’t know who to charge for it

Even by filtering ideas, we don’t know for certain if it’s really viable. Interviewing potential users, asking friends, getting “leads”.. It’s all nice, but the only validation is validation by credit card.

So whether people will really pay is what we need to test. But we must at least have an idea how to get users to our checkout form. If we either don’t know who the audience is, we don’t know how to find them, or we can’t charge them enough (depending on our $ARR goal), then it’s time to go back to Start and don’t pass Go.

Lastly, and this is related to #3 above, we also want these initial customers to be real fans. The idea must support creating real fans so we get vital feedback and organic growth. Obviously we don’t know yet if our idea will have fans, but it’s just as obvious that certain classes of products will never have fans, but simply users (i.e. don’t start a paper company).

5. The V1 of the idea isn’t simple enough

The only way to truly validate the idea is to charge for it (#4), and that most likely means building a V1. What’s possible depends on resources like knowledge, budget and time of course, so it must be simple enough to fit those constraints.

Another advantage is that a simpler product is often faster to sell than a large integrated solution which requires numerous stakeholders to sign off on. It’s also easier to explain what is and convince first potential fans to try it out. As building and testing a new idea is already difficult enough, keep things as simple as possible.

One category in particular to be wary of is “broad product ideas” with existing competitors. Where a deep product solves one particular problem really well (digs deeper than the competition in one aspect), a broad product is useful because it does many things in an integrated way. For it to be truly unique and better in some way (see #3), its V1 needs to do be either broader than the competition, or at least as broad and deeper. Both outbuilding and outselling complete existing platforms from day 1 is a bad idea when bootstrapping your first business idea.

Not all Startup ideas are created equal

Diederik • @jdvhouten • • Part of Day 1

Okay, so we have 80 days to build something. 80 days means 16 weeks at 5 workdays per week. We’re in Europe, after all!

0 to profit in four months. Two people. And we’re doing everything ourselves. We’ll be generous and consider anything that covers our hosting costs profit 😉

Now what can we make in four months that is useful enough to charge money for, and ideally, has broad enough appeal that it might grow quickly?

And that brings us to the subject of this post. Let’s that you have the technical software skills (or willingness to learn) to build pretty much anything, and let’s assume you have enough common sense to figure out the business side. How do your approach the problem of deciding what to build?

I’ve heard people argue, time and time again, that ideas don’t matter and that ideas aren’t worth anything. I know it’s fashionable to be contrarian on the internet, but let’s get real. Of course ideas matter. If you don’t have a good plan of what you’re going to make, how you’re going to make it, why people need it, how you will reach your audience, and how you will make money, you’re really just hoping to get lucky. A good idea doesn’t guarantee anything, but with a bad idea failure is a given.

The equation changes when you take outside investment. Friends, fools, and family. Angel investors. VC. When you’re spending other people’s money you can have a great career even when you run your startups into the ground.

Bootstrapped startups are fundamentally different. You’ve got to make something people are willing to pay for or you’ll fail. In my book that’s a good thing, and I think way too many people sit at the extremes. Either they work on hobby projects that have no chance of becoming self-sustaining (e.g. github projects that the programmers dream of working on full-time), or they go for disruptive moonshot startups (that have a tiny chance of making a huge impact). Don’t get me wrong, there is plenty of value in both but most businesses are going to be in the middle: regular products that people pay for because they solve some problems.

Okay, let’s zoom out a bit and consider our options. We’re good at software and we enjoy writing software. No surprise here: we’re doing a software startup. But the universe of software is large. So what kind?

Indie Game

Games we can immediately strike from the list. Building a game can be a ton of fun but making games for a living is absolutely unforgiving. The downsides are too numerous to list all, but these are the main ones:

  • You can’t know if your game concept works (meaning: whether it’s actually fun to play) unless you actually build it and play it. If you’re unlucky, you’ll spend the better part of a year before discovering your idea is no good and can’t be salvaged.
  • Games demand a high level of polish but are sold cheaply thanks to regular Steam sales on high-budget AAA titles. A low sales price implies the indie game dev needs high volume to recoup their investment. The indie dev also needs to cover the costs of the inevitable dud; breaking even on your successful games isn’t good enough.
  • Indie devs make most of their money in a single big sales spike when the game is new. This means you need a lot of marketing and hype going into it. Otherwise your game will languish on page 17 of some game marketplace. And that’s a real bummer, because your game needs to be a hit or you’ll go broke.
  • Which is the next problem. Indie game devs are completely dependent on 3rd party platforms for distribution. These platforms take a large cut of revenue and they have their own obnoxious systems for pushing updates and saving games to the cloud. This is going to take up time you don’t have.
  • No common platform. Want to support Windows, Mac, and XBox? You’ll have to do a ton of duplicate work and you’ll have to fight through many painful debugging sessions. And everything better work perfectly when you launch otherwise you’ll have angry gamers to deal with and all your effort will be for naught.
  • It’s effectively a winner-takes-all market. People want to play popular games with rave reviews. If you make a game that’s merely good in a category that has some truly great games then you’ll still lose.

It’s a cold and unforgiving world out there, especially if you’re an indie game dev. Thankfully, there are other options.

Mobile iOS app

When Apple launched their App Store over a decade ago a veritable gold rush took place. And for a good reason, iPhone users were eager to try new apps and the App Store made trying and buying apps super easy. For a few years you could make an app in any category and do very well. But the good times don’t last (they never do). Eventually the App market got saturated and prices were pushed down. People got used to paying 99¢ for an app, and at that price point indie devs can’t really sustain themselves. Combine that with competition from free ad-supported apps and that’s that. It’s a race to the bottom where app developers have no pricing power and Apple still takes a 30% cut.

Even if you beat the odds and build a successful business on the App store you can still get kicked off without notice, your updates might get rejected, or your product might get shamelessly cloned by Apple. Apple can’t be reasoned with, can’t be bargained with, and it doesn’t feel pity, remorse, or fear 🙂

Android’s ecosystem isn’t any better. The verdict here is clear: don’t build an iOS app unless you’re happy to submit to Apple’s arbitrary and capricious ways.

Desktop App

Web tech is pretty much broken. On the server side it’s not hopeless because you are fully in control of the stack. Client side? You’re stuck with CSS and Javascript or a myriad of languages that sort-of-but-not-really have CSS and Javascript as compile target. You can use OpenGL, or a subset thereof, WebGL, but it’s buggy and doesn’t work on mobile devices. You have offline storage, with IndexedDB, but no guarantee the data you save will actually persist. And the web is insecure by default, which means you’re always one typo away from catastrophe. I’m sure we’ll write extensively about web security in the coming days and weeks.

If the web is such a mess, clearly the solution is to write a desktop app, right? Well, no. The web gets one thing right and that’s distribution. People can just click on a link and they’re immediately in your app. Within 30 seconds you may have caught their interest and after that they’re hooked. By contrast, if you have a desktop app you need to persuade people to download the app using your website, YouTube, or by other means. If your software is actually good you want people to experience that for themselves, but if you write desktop software you’ll lose the majority of prospective customers before they’ve even downloaded a free trial.

The distribution model for desktop software desperately needs to get solved — not by app stores but by sandboxing. Let people freely download and try software without having to put their entire machine at risk. This requires a major change in direction by Apple and Microsoft who are both committed to the distribution model of curated app stores. I really hope desktop apps will make a comeback, but until distribution, cross-platform, and security problems are addressed I don’t see it happening. Until then indie devs who make desktop software are fighting an uphill battle.

Hobby/leisure/marketplace app

This shouldn’t really be a category by itself, but I see too many techies take the advice to “scratch your own itch” too literally. There is no shortage of minor annoyances in life but very few of these problems can be solved by software.

In this category I’ll also include marketplace apps that don’t solve real problems. You don’t need an app to keep track of which neighbor borrowed a lawnmower. That’s not to say marketplace apps can’t work, but they’re notoriously difficult to bootstrap. If you really want to go this route build a hobby blog/community first and grow a large audience. This will take at least a couple of years. After you have a captive audience you can start the marketplace service. Marketplaces need a critical mass of buyers and sellers, otherwise it provides no value, and you can’t bootstrap that from zero.

This means, unless you’re already running a community website of some sort there are better options elsewhere.

Enterprise Web App

When we talk about Enterprise software we mean software that’s used by larger businesses. The fundamental difference between software for the Enterprise and Small/Medium sized businesses (SMB) is in the sales cycle and the kind of support the Enterprise customer demands. And Enterprises only like to purchase software from established companies. If you’re a bootstrapped startup you don’t have the time to engage in contract negotiations, extended talks, product demos, and other handholding the Enterprise customer expect. That sucks, because it means you won’t win the customer even if you have the “best” product.

Many Enterprise software products are qualitatively bad, but entrenched. If you want to disrupt a market like that you’re going to need a team of engineers to quickly reach feature parity with existing solutions and you need a sales team to push your software. There is also a general lesson here. If you’re thinking about entering a market where the existing solutions are suspiciously bad, don’t ignore that feeling. It might mean that the people who make the purchasing decision are far removed from the people using the software. And that, in turn, means that you can’t win by making better software.

In every Enterprise software market you have to compete with entrenched players and lavishly funded startups that will happily lose money for a decade if that’s what it takes. As a self-funded bootstrapped startup you won’t stand a chance in direct competition against them. Some markets belong to VC backed startups, and this is one of them.

Plugin/extension/integration to existing platform

This is the first software category that has real promise for independent bootstrapped startups. Any business that grows quickly has users clamoring for extra functionality that’s not in the main product. That is where you can find good opportunities, because it’s so obvious where your potential customers are and it’s easy to reach them. In many cases the platform business is eager to highlight and market add-ons/plugins and the like because it allows them to solidify their position in the market.

You can write an add-on for enterprise products like SAP or SalesForce or for SMB products like Slack, Stripe, WordPress, Google Workspace, Office 365, and many others.

The biggest downside with businesses like these is that they don’t last. Why? Because the platform business can see exactly which plugins/extensions are popular and just clone the best ones and turn them into native features. In a sense you’re competing with the platform that you’re also entirely dependent on. This puts a ceiling on how successful your add-on can be. But if the big fish is big enough, and some of them are huge it’s still very much worthwhile.

Prosumer/freemium webapp

Freemium apps are apps that users can indefinitely use for free but they can choose to pay for a premium version that offers some extra functionality. It’s all about scale here. If you have enough users you don’t need to make much per customer to have a nice business.

A typical strategy is to start by giving away your software for free and enjoy the hopefully exponential growth in free users for as long as it lasts. When user growth starts slowing down you introduce a paid (subscription) plan and a fixed percentage (3% maybe) of users will convert. For bootstrappers this can result in a real painful dilemma. Because you want to wait as long as possible before you exchange exponential growth for linear growth + revenue. But if you’re running out of money you might get forced to start charging for your product prematurely.

The cool thing about freemium apps is that you can get many users quickly, the only problem is monetization. And that’s a big one. Go this route if you think you can make something that appeals to millions of people.

SMB webapp

The SMB segment is underserved when it comes to software. They need software to run their businesses and they have money to spend but Enterprise software businesses don’t cater to their needs. SMBs generally want simple software that “just works” and that they don’t have to worry about. Small companies will happily pay $50 to $500 a month for anything. It’s not much money when the alternative is hiring additional staff. For every 1000 customers paying $100 a month you’re making a million in revenue. 1000 isn’t a large number. If you’re willing to grind your way through you’ll get there eventually.

The only real difficulty here is reaching your potential customer base. SMBs don’s spend their days googling for software that might help them with a problem they have. If you have a good product in this segment marketing will be your biggest pain point.

But if you keep growing your customer base and keep improving your product you’ll be able sell to the lower end of the enterprise segment as well. It’s a good place to be. It just takes a long time.

Near universal truths

Let’s zoom out a little bit. When you make a product you want to make something…

1) that people will use regularly and that solves some pain they have. If they’re not using your product regularly they’re not going to be exited about it and talk about it.

2) that people, and ideally businesses, are very happy to pay for. Basically you want to look for indirect competitors. If there are plenty, that’s a great sign. If a single business has a stranglehold on the market, think twice.

3) that you can prototype relatively quickly. Established businesses can create prototypes for products that will go to market a decade from now, but you can’t afford to. You need to move fast and get it out there.

4) that has an audience you know how to reach. Tech people don’t like marketing, and we’re no exception. But if people don’t know your product exist they won’t try it, and that’s no good. If you’re doing something you’re excited about it’s much easier to talk about what you’re doing, and that’s the essence of marketing.

5) that is unique and clever in a way that’s hard to replicate. You don’t want to clone somebody else’s product. It’s uninspired, the customer can tell, and it almost never works.

It can be hard to make sense of all the contradictory advice you find on the internet. But it helps to remember that funded and bootstrapped startups play by completely different rules. You also have survivorship bias: startups that succeed despite the odds are unaware of how lucky they got. One of the biggest hurdles is going from nothing to making a symbolic amount of money. You want some indication that you’re not crazy and that there are actually people out there that like what you’ve built. Once you know you’re on the right track you’ve just got to keep going. The first part is where tons of people get stuck.

We hope to show people with the 80daystartup what you actually have to do to launch a commercial web app.

Spoiler: it’s actually a lot of work. But we’ve done this before and we know what we’re signing up for. Here we go!