Day 11

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

Today's posts:

Recap week #2

In the first week of this 80 day journey we figured out what to build — an editor (IDE) but specifically for task planning.

Last week we created the first mockups for our app. Extremely preliminary stuff, of course. Expect everything to change. Our editor we’re building entirely from scratch. That means we have to do layout, line-wrapping, selection, keyboard shortcuts and everything else ourselves. But once we have an editor that works we’ll be able to all sorts of cool stuff.

Wim started live-coding on Twitch as @wcools. You can watch some replays where Wim works on a virtual scrolling component for our editor.

Last week we also wrote some articles on our blog. We wrote up our Initial marketing plan and we wrote about our server architecture in A no-nonsense server architecture for group based SaaS. On a more philosophical note, in Choosing the hard path we argued that for technical founders it makes sense to tackle hard technical problems for their startup, even if you have serious time constraints (like our self-imposed deadline). Our hope is that by building a product that delights users it can spread through word of mouth.

What’s next

We have two major themes for this week. Technical prototyping and UX design. We create technical prototypes to figure out if we can make our innovations work in the time we have. We’re on a tight schedule and we need to figure out which parts of the app are hard and most demanding of our attention. Hopefully we’ll catch all the unknown unknowns in the coming week or two.


Thanks for following our story! You can see our daily updates on Twitter (@wcools and @jdvhouten). Or drop us a line at [email protected] for any reason. We’re always excited to hear from people πŸ™‚

You don’t need the cloud

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.

Your MVP needs to Spark Joy

It’s common startup wisdom to launch as soon as possible and be slightly embarrassed [1] about the first version.

I often see new launches where people take this advice too literally, as if any kind of polish is premature optimization. The hard part of course is knowing what the M in Minimal Viable Product really is: what parts can I leave out? There are certain things you can be embarrassed about, yes, but some things need to be really good about it.

I almost never see an MVP take off for which the core experience is not super polished. It’s more than polish actually. Something about it sparks joy, is delightful or whimsical. You want to tell others about the great experience you had.

You need initial super fans for your product to take off. Yes there are a few exceptional idea planets which have such low escape velocity that any solution goes, but most ideas are about execution. Indifference about your solution is the enemy of a new product, so you need to make an impression and stand out.

It’s embarrassing to ship your product without a password reset. It’s embarrassing to ship a smartphone without copy&paste [2]. But none of those things matter. They’re not what makes you unique, they don’t define the experience. You can get initial fans without.

You need your own version of completely useless but cool animations [3], rubber band scrolling [4], handwritten post cards to first customers or even whoopee cushions and light shows [5], or a funny demo video [6]. This is what gets press and what people tell their friends about.

Put in the creative work to make your MVP stand out in such a way that you attract initial fans. It doesn’t even need to be a lot of work, and especially for technical founders this is the kind of marketing that should be fun. Turn those early adopters into fans, and make the first impression of your product really great. Worry about the long tail feature stuff later, but at least some people need to think “wow this is cool”. That’s what’s part of the M in MVP to me.

[1] https://twitter.com/reidhoffman/status/847142924240379904

[2] https://www.engadget.com/2009-03-17-iphone-finally-gets-copy-and-paste.html

[3] https://www.youtube.com/watch?v=2GkoAa5718Y&t=113s. I could watch this all day.

[4] https://www.youtube.com/watch?v=FSv5x3V_KHY

[5] https://www.youtube.com/watch?v=Xg_0NRi-OxE

[6] https://www.youtube.com/watch?v=7QmCUDHpNzE

Always build the hard part first

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.



← Previous day (day 10)Next day (day 12) →


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