Day 18

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

Today's posts:

It’s not 0 or 1

It seems binary thinking is not prevalent in just tech founders but when starting a business in general. Often people seem to think something needs to be done perfectly, or it isn’t possible. If that’s reason not to pursue your dream of building a product/business, that’s a shame because you can slowly work your way from 0 to 1.

All at once

At every stage in the business, you’ll deal with other issues and challenges. It’s okay to learn while doing and deal with them as they occur, otherwise it would become impossible to start. Thinking you have to do everything all at once means you can’t really start with anything.

In the beginning you don’t know yet whether anything you’re about to do will really matter. That’s when it’s best to worry about “bad problems”. That’s not a pleonasm, because there are “good problems” too. A bad problem would be not having any customers yet. Focus on that. A good problem is having so many customers that you can’t handle support anymore.

Spending time on fixing good problems you don’t have yet is a waste because it might never have been needed in the first place. Plus you won’t really understand yet what the best way to handle it is until later.

All in

Starting a business doesn’t mean you need to drop everything else. We started building our first software business when we were students. We did freelancing and work for university on the side. Admittedly it was a very busy time, and we promised ourselves to switch to full-time as soon as we financially could, but we managed to grow to our first product in this way and become ramen profitable

Going all-in when it’s an option is great, but sometimes the timing isn’t right and starting up on the side is totally possible. See if you can get a first customer, then scale it up. 

Doing less

Some things which need attention can also be fixed with a duct tape solution, and then revisit them later when it becomes really painful. For our first app we didn’t even have a password reset option. People had to email us and then we’d reset it for them, manually. We just didn’t have the time, and if we would end up with 0 customers it would have been a waste of time to invest in. 

Technical founders also like to set up their perfect environment and tech stack. Kubernetes, CI/CD, Docker, Microservices, the list goes on and on. It’s all a waste of time if you don’t have a product with customers yet, and you just won’t need it. Duct-tape it together with whatever means necessary for now (that actually sounds worse than it is, I like to think of it as just going for a simple and elegant solution). Worst case it takes off and you get to improve it while being paid for it.

Copying the big league 

Because big businesses are more visible, their approach sometimes seems like the only way to do anything. But just like when they were small, many of the challenges they have are not relevant to you.

Just because Netflix has servers all over the world doesn’t mean you can’t run your entire business from a single computer under your desk. Focus on getting some customers first. You don’t need to worry about a few minutes downtime yet (if you have any people noticing at all then that’s a Good Problem).

Just because Google is tracking the usage across their apps and A/B tests everything doesn’t mean you even have the numbers to make any of that relevant. Just get feedback on your product first.

As a founder you can (and have to, initially) do everything yourself. You are the sales department, the financial department, the technical department, the support department. Customers are not going to mind if you provide a good service. Besides, from which company you recently dealt with did you get a personal note from the CEO when you had a question. How amazing is that in terms of support?

Lots of founder also seem to worry about all kinds of legal paperwork being so complicated they don’t get started, and overestimate the problems they will get exposed to. You are not going to have the same responsibilities and issues as Amazon. Many exemptions apply to small businesses in the first place, but even the big players don’t have everything perfectly set up. Lots of things you can do yourself. For example, the entire GDPR framework is explained on a website which you can read in a day, problem solved. You don’t need expensive consultants for that. Same for accounting, just go with something simple or do it yourself for now.

Get building and find those first customers!

Thymer – a rough feature list

As we narrow down what our productivity/planning app Thymer will be like, we move more and more to the “no” column. Or to the “not yet” column, which is exactly the same as “no” but easier to swallow.

Some functionality we consider essential. Those are the core features that people will be using all the time. Long tail features are features that make the product better, but that don’t excite people and don’t make your product stand out. For an MVP you want to focus on core features and BS features exclusively.

As a reminder to myself that saying no should feel painful, here is a clip of Jony Ive talking about it:

Okay, here we go. A shocking amount of work to do. It’s still a pretty rough list because it’s still early and we try to keep an open mind about what’s important and what’s not. It’s pretty likely that the MVP will deviate a ton from what we describe here. But that’s OK.

Core features

  • The editor. This includes multi columns, line wrapping, virtual scrolling, indentation, sorting, searching, and everything else you’d expect an editor to do.
  • Command menu. Popularized by sublime text, but now also used by VSCode and many other apps. Basically instead of littering the interface with buttons and dropdowns you can have a list of commands that the user can search through with auto-completion. Shortcuts for the popular commands.
  • Planning layout, where tasks can be assigned to one or more users. This is where you get a sense of what has to get done.
  • Zoom in/zoom out. So you can focus on one part of the document.
  • Offline first. For the app to feel responsive keep track of all changes and send those to the server later. No spinners every time you do something.
  • Flawlessly sync changes made by multiple users, and resolve conflicts where necessary.
  • Conventional task features. Mark complete, in progress, done, important, waiting for something else, due dates, etc.
  • Onboarding tour. We want people to try our app without getting overwhelmed.
  • Very basic settings/preferences. Close account.
  • Splash/marketing website. Has to explain what Thymer does and why it’s worth trying.
  • Group management. Add/remove users from your team.

Things we really want (time permitting)

  • Real time multiuser support. When two people work on the same document each should see the other person type. This is super hard to add after launching, so we want to have it working by the time we launch.
  • Versioning. One of the great benefits of using pen & paper for note taking is that you can so easily go back to your previous notes. Most software products are terrible in this regard, and we think we can do better. For this we need to make some kind of system that allows the user to go back in time, see changes, and so on.
  • Billing/invoicing. Would be nice to get this done before the launch. Otherwise we just have to scramble after the launch to get it done.
  • Client side API with a console/shell. We believe apps should be programmable by the user. We can’t put buttons for everything in the user interface, but we can expose many of the internals to the user so they can go wild.
  • Bulk actions, of all sorts.

What we probably won’t have time for

  • Calendar syncing with Google/MS Office/Apple calendar. Having to use a planning app and a calendar side-by-side isn’t great. The problem with calendar syncing is that it’s just another feature, except it this one takes a disproportionate amount of time to get to work right. Once we have users I have no doubt many will start demanding calendar integration. But it’s something we can postpone for now, so we do.
  • Email notifications when team members make changes. Email summaries for changes in a day/week/etc. Nice to have, of course, but it’s something that can be cut, so it gets cut.
  • End-to-end encryption. Because almost all logic is client-side already, end-to-end encryption is doable and certainly a nice feature to have. We are pretty paranoid about security ourselves, and we think it’s a good thing when e2e encryption becomes a standard practice. It’s not without downsides, though.
  • Super advanced editor features, like block selection or multiple cursors. Copy-pasting rich content between browser tabs.
  • User documentation or manual.
  • Theme support. Dark/light mode.
  • Extensive customizability.
  • JSON API

BS features

  • Cool animations
  • Tips & tricks
  • We’ve got many wacky ideas. But it’s a distraction for now. BS features we’ll add in the final stretch.

Definite no

  • Mobile app of any kind. Definitely no iPhone or Android app. Making a good mobile app for anything is a big project. We think in most situations an MVP should be either for desktop use or for mobile devices. It’s pretty unusual for apps to have a 50/50 split in desktop/mobile usage, and for light apps a mobile-first design is still usable on the desktop.
  • Extensive browser support. If it works on Chrome (and maybe Safari/Edge) we’re happy.
  • Localization. English it is.
  • File attachments. It’s just another long tail feature.
  • Desktop app. Some day, I’m sure. Do we want to mess with electron on some kind of cross platform UI framework right now? Nope. No time.

As you can tell, our ideas at this point are pretty vague. As Thymer starts to take shape we’ll get a better sense of what is really critical. With only 60 days or so to go I expect we’ll be forced to cut even more from our “must have” list.



← Previous day (day 17)Next day (day 19) →


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