Diederik van Houten


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Where are all the software startups?

Diederik • @jdvhouten • • Part of Day 13

Where are the software startups? Where are they?[1] It’s a question that’s been on my mind for years. I don’t get it. Clearly many people want to work on their own software. The abundance of open source software is evidence for that. Clearly people want the independence you get from doing your own thing. Clearly people want to be in charge of their own destiny. Clearly there is a market for software that doesn’t suck. Technology is still in its infancy. Most software hasn’t been written yet.

How can it be that this market mismatch continues to exist. People with money to spend are clamoring for better software and there is an abundance of skilled software engineers and designers who want to make high quality products. Where does the software market break down? What’s going on here?

I can’t blame the potential customers. They can’t buy software that doesn’t exist. Nor can they buy software they have never heard of. My best answer is that people who really should be doing a software startup overwhelmingly don’t.

Are the incentives wrong? Doesn’t look like it from my vantage point. What do startups offer? Unparalleled freedom to pursue an idea you’re passionate about. Financial rewards when you make something people want. The satisfaction of bootstrapping something from nothing. A sense of independence and self-reliance. The absence of office politics and other nonsense.

And yet, we’re stuck in a place where most software kind of sucks[2] and software hasn’t gotten any better in the last 20 years from my vantage point. This is not just me being cranky. I’m trying to figure out why more people don’t get out there and make better software and enjoy the spoils.

[1] In Europe there are very few software startups. If you live in SF you might not agree with the premise there are few startups.

[2] You can’t even copy-paste rich content between a word processor and gmail. Apple Notes spins at 100% cpu unless I switch to “card layout”. My receiver crashes and loses its wifi connection. Nothing just works. Computers are fast but software is agonizingly slow. No software is truly cross-platform.

Build one to throw away

Diederik • @jdvhouten • • Part of Day 12

Any time you try something new you don’t know how it will turn out. And your first attempt at anything won’t be very good. You don’t have to feel bad about this. It’s just how it is. If you know in advance that something will turn out great you’re probably working on something too easy.

With the knowledge that it’s counterproductive to pursue quality prematurely, you are now free to focus on something else: discovery. Be curious. Be open minded. Build something wacky. Experiment freely.

If all good design is redesign and all good work is rework then you have already decided you’re going to throw your prototypes out. This means you don’t need to worry about having to scale to a million users. You don’t have to worry about having “the best” architecture. You don’t have to worry about every pixel being in the perfect place. Take shortcuts. Stub out what you can. Copy-paste freely. It doesn’t matter.

You’re free. You’re free to work directly on your core innovation. That thing that makes your app interesting and unique. The less code you have the easier it is to move things around, delete, and rewrite. It’s at this time that you can hone in on what works and learn what doesn’t. It’s this phase of experimentation that will determine whether you’ll have mediocre or exceptional product/market fit down the road.

Spending extra time in this exploratory phase doesn’t guarantee you’ll get a good outcome, but it helps for sure. Knowing it’s futile to pursue perfection in means you can take ugly shortcuts with a clean conscience.

Of course, in the long term you do want quality. Of course you want to make a product you can be proud of. But in order to get there you’ll need to experiment.

That’s where we’re at for the time being. We want to figure out what works. We have a couple of ideas that we want to explore. Does it make sense to use a text editor for everything? Do we want our app to be offline-first and collaborative at the same time? Are we on the right track? I don’t know. Nobody knows.

We build and throw away. Build some more and throw away. With our 80 day deadline inching closer it’s difficult to resist the temptation to rush forward. To start building the app for real. But we can’t. Not yet. First we prototype. Then we build the MVP. Then hopefully we’ll end up with an MVP that sparks joy.

Recap week #2

Diederik • @jdvhouten • • Part of Day 11

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

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.

Design sketches

Diederik • @jdvhouten • • Part of Day 10

Rough UI sketches for our app. It’s going to take a while for it all to come together. Most of what we design in the very early stages won’t make it in the final version, but this time is critical for us to figure out what’s really important and what can be left out.

We know we want an editor-first experience, because typing is fast and natural. It doesn’t slow you down when you’re thinking. But we also want a structured environment so you can plan tasks and deadlines in the future and not have them get lost in the noise. Because task lists get moved and shuffled around constantly (at least if you’re like me) you want an interface that encourages this free-form use.

80 days is not enough time to get everything right, but if we get enough right we can fix our mistakes in a Version 2.0 down the road. Skipping over the ideas and prototyping phase won’t get us to the finish line any faster.

I’m going to sleep on these ideas during the weekend. Many of our Great Ideas turn into “what were we thinking!?” days or weeks later. Funny how that works. It doesn’t bother me, though. Worst case we’re going to need another complete redesign cycle or two. Best case our ideas start to converge from here on out to something with a strong conceptual core. Then we can start heads-down-coding and we should pick up speed!

This wraps up week 2 for me!

State of the Startup

Diederik • @jdvhouten • • Part of Day 9

Ten days ago we announced we were going to do our 80 day startup. Except we didn’t have anybody to announce anything to. We knew getting any kind of audience wouldn’t be easy. We’re over 10% in, so what do we have?

The stats

Traffic for this blog is at about 50 visitors a day. But the visit duration is 6 minutes, which is suspiciously high. I’m pretty sure that half the traffic is just the two of us, reading each other’s posts :).

We use plausible.io. It’s GDPR compliant and we’re happy customers.

We don’t have any charts for Twitter followers. Wim has 38 followers, Diederik (that’s me) has 19. Yep, this is going to take a while 🙂

In the past week and a half we’ve written 20 blogposts. First time blogging for us. Hopefully we’ll be able to write more quickly as we get used to writing. As we get deeper into coding we won’t be able to spend two hours on a blogpost anymore. Instead we’ll just post about the technical issues we’re dealing with.

We also have a mailing list where we send a weekly summary of everything we’ve done. That mailing list has a grand total of 29 subscribers. That includes the two of us, naturally.

For completeness:
Users: 0
Customers: 0

That’s it. At about 20% of our 80 day journey I’ll do another stats update.

Choosing the hard path

Diederik • @jdvhouten • • Part of Day 8

Often people rush to get their product out the door. From idea to customers in a week. Although that might sound appealing at first glance, there is a big downside: it limits your startup ideas to those that are very easy to build. You can’t do any cool tech in a week, nor in a month. Good software takes 10 years, as the classic essay goes.

Any time you create an MVP there are two outcomes. Either it turns out your idea has some legs and you continue building. Or you discover that your idea was no good. This means your MVP can’t just be a couple of screenshots or a splash page. You might use that to drum up some initial interest, but it can’t tell you whether your product will be any good. For that you need to make the thing and see if people want to use it.

And if you can make the core of your product, at least enough for it to be usable, in a week (or two) then other people can as well. It means there can’t be any real tech beating at the heart of it. The startup has to be about something else. Perhaps it’s some kind of #nocode tool that links together a couple of services. Nothing wrong with concepts like that, but if you can get your startup off the ground without having to build any tech innovation then it’s not going to be a tech startup and you won’t have a corresponding competitive technical advantage. More importantly, we enjoy coding and simply want to have a startup where the technical quality of the product matters.

We’re giving ourselves closer to 4 months (80 days is 16 weeks) to build our MVP, for an idea that is as conceptually simple as it gets. We want to build something in this productivity space that hasn’t been done before. We have some rough ideas, but we can’t know yet if we can turn it into a cohesive whole. That means prototyping, and sketching, and more prototyping until we have something that we think is original, visually distinctive, and shows real promise.

Now that we’re more than a week into our startup it’s becoming evident that even if we scrap everything that’s non-essential there is still a lot left to do. We’re thinking of building our own editor environment from scratch, with real-time multiuser support, and all sorts of synchronization logic. Extensibility? Maybe. In any case, there are many design decisions to make.

We’re doing #buildinpublic because it puts us out of our comfort zone. It’s easy to adopt a “it’s done when it’s done” philosophy, but that isn’t wise. An 80-day deadline forces us to focus and hopefully that will result in us making better product decisions. It’s a tight deadline, but not impossible.

Let’s see if we can build some substantial tech in 80 days. We’re choosing the hard path and we’ll find out soon enough.

A no-nonsense server architecture for group based SaaS

Diederik • @jdvhouten • • Part of Day 7

If you’re never built a SaaS product before all the server-side stuff might seem overwhelming. How many servers do you need? Magnificent monolith or microservices? VPS, app engines, end point computing, dedicated machines? Do you need a CDN? SQL, noSQL, distributed or not, failover, multi-master or RDS? So many decisions! And if you get it wrong it’s going to cost you.

Thankfully, we’ve built SaaS products before which means we’ve got a rough idea of the kind of problems we’re likely to encounter at different levels of usage.

Our guiding principles:

Don’t overspend

The cloud is great in many ways but the virtual machines are underpowered and expensive. Cloud servers make perfect sense when you don’t want to do sysadmin work or when your load is so unpredictable you need to dynamically spin up additional servers. Neither applies for us. A single $100/month dedicated machine gets you 16 cores, 128GB ECC ram, and 8TB of enterprise NVMe SSD storage. That’s a lot of horsepower!

A single server like that can support more simultaneous users than we’re ever going to realistically have. We could probably get a server that’s one third as powerful and not notice the difference. We won’t need to heavily optimize our server code and we won’t have to worry about communication between microservices. A monolith is simple and that eliminates entire classes of bugs, so that’s what we’re going for.

Boring tech is better

We’ll use Debian stable. We don’t mind that all packages are 9 months behind other distributions. We don’t need the latest point release of bash or Python. We want stable packages and regular security updates. That’s what Debian offers.

Django + MySQL is will be the core of our backend stack. Because our SaaS app will be group based (meaning: no shared data between groups) scaling and caching will be very easy. Servers like twitter are complex because every action potentially affects any of the other billion users in the system. But when you make a service where all user groups are independent you don’t get this explosion in complexity. If we suddenly end up with millions of users (yea, right!) and there is no faster server available (vertical scaling) we can still scale horizontally if necessary. It’s just a matter of buying a bunch of servers and evenly dividing our users between them.

We have used Python/Django for years so that’s what we’re going with. We could have picked golang or any other web stack. It doesn’t matter that much.

We don’t need a cache server, a message queue, or any other services at this point.

We should get 99.99% uptime with this server architecture, simply because there is so little that can break. Provided we don’t do anything dumb :). All downtime is bad, of course, but there are diminishing returns at some point. I think 1 minute of downtime per week is acceptable.

Security Paranoia

We’ll cover this in depth in future posts. Firewall, sshd policies, full disk encryption, and intrusion monitoring are core parts. The mantra is: layers of defense. If system files get changed, we want to know about it. If a program listens to an usual port, we want to know.

We’ll do backups with rdiff-backup (local + remote). We can use it to diff what changed on a server, which means it also functions as an audit tool. What makes rdiff-backup so cool is that it computes reverse diffs, as opposed to forward diffs. This means the latest backup set consists of plain files that can easily be verified to be correct. In addition there is some compressed archival that allows you to go back in time for individual files/directories. You never have to worry about the archival system getting corrupted.

For full disk encryption we’re going to need to employ some tricks. We want to encrypt everything, including the OS. For a remote headless server that requires some ingenuity. More about this later.

Mailgun

Mailgun is what we know so that’s what we’ll use for our planning IDE Thymer. Mailgun has always had reliability issues though and deliverability is mediocre, even when using a dedicated IP address. We can always switch transactional email providers at some later point, so it’s not something for us to worry about now. It would just be a distraction.

Cloudflare

Our app server(s) will be in Europe (because of GDPR), but most of our users will be in the VS. That’s not great from a latency point of view. It takes a couple of round trips to establish an SSL connection and if you have to cross an ocean that will make your site feel sluggish.

Cloudflare has many end points globally, and we want our app to load fast. We’ll move all static content to Cloudflare and we’ll make sure to design our app so it can load as much in parallel as possible. Cloudflare also provides us with free DDoS protection and their DNS service is great. One day Cloudflare will start charging startups like ours and we’ll gladly pay. For now, the free plan suits us just fine.

We’re bootstrapping and we’re running our startup on a shoestring budget. Everything on this list is free, except for the server(s) and those are dirt cheap. It’s almost comical how easy and cheap running online services has become. Most of the hip new tech we just don’t need. Our app will be client heavy and the server will be little more than a REST API and billing logic.

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!