Day 5

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We're building a startup in 80 days in public. Day 5 was on Jan 14 '22. You can find today's entry at Day 67.

Today's posts:

Skills you need to bootstrap a SaaS startup

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!

Name + domain

Day 5, and time for a bit more brainstorming about the roadmap and the idea. One of the things on the agenda: naming the app. We’ve picked Thymer.

Picking a name can be difficult but we don’t really have too many magic tips here, it’s a mix of inspiration and luck a name you like is not taken by something similar. Some considerations:

  • We usually try not to go with something too generic like say apple, although that seems to have worked out OK for them. It helps of course if it’s easy for people to find you when searching on Google, Twitter, and so on. Likewise it helps if you can find it, so you can see where people are referring to your product.
  • We still like .com, keep it simple.
  • For a lot of people the browser’s address bar is Google, so they don’t type the full domain but rather the name. That makes it difficult for them to find what they’re looking for when you’re on page 20 in the case of a generic word.
  • Not that we always do this right, but it helps if your target audience can pronounce it 😉
  • Some top level domains might come across as spammy. Some might be associated very strongly with a different brand already (which can of course help if you create something like a plugin for another product). Some countries also have some requirements your business is from there, or suddenly introduce extra paperwork. Some are really trendy, which can be a good signal to early adopters; you also run the risk that in 5 years from now it sounds very stale though. Some have all of that (startups which used .ly back in the days)
  • When in doubt, it seems a trend is to just take two words which form something catchy together. Even if those are generic words, the combined name won’t be generic. SuperList, PhoneMagic, InboxMountain, etc. I think this trend will stick longer than some others (like the early Web2 days names such as Twttr, Flickr) as it’s easy to come up with, pronounceable and there’s a lot of combinations (which helps with most short domains already being taken). Another benefit is people might already get what your product is from the name.
  • In our case we liked the idea of something new while trying to refer to the product a bit, something related to productivity (getting more out of your day/managing time).
  • In the end, the name is not super important. It won’t make or break your product as long as it’s not completely terrible.

In our case we still had the domain lying around, unused for like 10 years (a story for another time). For now thymer.com simply redirects to this blog, as we don’t have any visitors yet anyway. We’ll start working on a proper landing page some time soon.



← Previous day (day 4)Next day (day 6) →


You can follow us on Twitter @jdvhouten and @wcools and look for #80daystartup

Read more

Work/new-life balance
Durable tech
Dogfooding
Early user feedback
Spending time to save time
Products want to be platforms
Always be launching
Enjoying the journey
Work-life balance
Recap @ Day 59
Perils of caching
Desktop-first
Making sense of contradictions
Trust signals
DIY javascript error logging
Taxes: an automation story
Magical thinking
Start small
High conviction, low conviction
Most deals fail

Post archive