Earlier this month we wrote about the importance of taking breaks so we can keep running these rollercoaster marathons, which is what running a startup is in many ways.
You might have noticed we’ve started another break, this time because of some happy personal news: I became a father a few days ago! I’m happy, proud, and as to be expected, exhausted ;).
So it’s time for me to take a break and enjoy time with our little addition to the family (the 18-year startup!).
Whenever one of us takes a break we’ll just pause the project/blogging here, as we’re also running our existing business in parallel with this project. We’ll be back soon to continue with daily updates on the work towards finishing the MVP and the launch for Thymer!
Just like it’s easiest to come up with a product idea by solving your own problem, the best way of figuring out how it should work is by dogfooding, i.e. using your own product.
For some of the problems we want to fix with Thymer it’s very clear how the app should work and solve them. These are things we’re currently trying to do with a plain text editor but don’t work well. In a way, the workarounds we’re using now because the app doesn’t exist yet are a sort of pre-MVP prototype, giving us plenty of ideas to work with.
For some elements of the app, we know what problem it should solve, but we don’t know yet if a solution we came up with on paper (literally, as a paper sketch is usually the first step) works really well. That’s where it’s helpful to build small prototypes to bring the idea to to life.
It doesn’t need to be complete yet, but just enough so we can actually start using these parts of the product and see if this matches the experience we had in mind. Over time a product will change a lot anyway, but making sure the core works really well by using it ourselves helps getting an MVP out with enough initial fans to get more feedback where to improve in the first place.
It’s not always possible to dogfood every aspect of the app yourself. Our existing product for example is used by companies 100x our size. In this case it’s still important to test the app, using a sort of test persona, i.e. trying to think like the end-user and about what their workflow might be. Another useful tool is populating the app with test data. If we’re a team of two and only have two items in a list, but our target audience persona works at a company of 100, what happens if we add a 100 items? Usually this goes a long way towards fixing the most obvious problems.
Thinking about these UX/UI issues from the beginning can feel like premature optimization, and of course launching a new product is always a bet in a way. But simply sitting back and waiting for feedback to roll in is not without risks. If an MVP doesn’t feel polished enough in the right places, users might drop off before you get to hear about these issues. Another problem is that fundamental design decisions regarding the very core of the app are very costly to fix. To take the example of our existing product again, we originally shipped with a permission system which was too complicated when teams had dozens or hundreds of users, and those are our best customers! As you can imagine, permissions touched pretty much every part of the app, so we could have saved a lot of time getting this right from the beginning and not having to change it later on.
You can usually tell when products or services aren’t really used by those who designed it. They’re often confusing or come with very obvious mistakes, which everyone would run into it, if only it was used enough. The same is true for individual features within an app. That’s why we try to avoid having too many core features we can’t dogfood ourselves.
Sometimes you’ve thought a design over many times, made a bunch of sketches and think you have a clear idea about how everything works. But sketches and prototypes are very rough by design, so it’s easy to look at the same sketch in different ways, or discover some parts of the concept need more work when you start working on the nitty gritty details.
Although everything about a startup and launching an MVP shouts “ship ASAP! ship yesterday!”, quite often taking the extra time to think things over a bit more helps making sure you take the right turn, which saves a lot of time down the road.
Today we spent most of the day meeting and going back to the drawing board about some design decisions for Thymer’s core features.
Having worked on the app a bit more by now, what features do we really find important? How do we keep the scope for V1 small? How do we balance the fine line between making a product too narrow to be useful, or making it too broad so it automatically gravitates towards becoming a platform with unlimited scope. The USP of Thymer is it’s a powerful IDE for people to get things done. Part of the “internal USP” of this product is that it won’t take years and VC funding to build. We need to make both of them work.
One feature we talked about for example is related to dates. Thymer has some notion of dates, which is important for planning. Not doing the “hard work”, actually thinking through what this means and how it should work, most often leads to the wrong solution by default: the one easiest to come up with and hardest to make.
In this example, that would be a calendar. But jotting down some thoughts on what to work on tomorrow is different from a tool where people schedule an appointment with multiple participants using a start time in timezone A and an end time in timezone B. It’s not Google Calendar, which is a completely different product in and by itself. Not only would building all of that be way too much work, it would offer nothing new, and it would make the product less interesting, watering down the vision.
So we looked at how the concept of dates within the scope of the app is actually useful, what parts you need, what parts you don’t. In what way it wouldn’t conflict with using other tools like an existing calendar on the side.
In terms of scope we also looked at some other features we most likely won’t be able to build in V1. For example, in the case of end-to-end encryption (E2EE), we need to make sure that we don’t take decisions now which will rule out being able to encrypt data on the client. Another example was mobile access. Although we can’t launch a dedicated mobile app when we launch V1, we thought about whether a companion mobile version, just covering the most important use cases for on the road, would be compatible with our idea of the core version of the app.
We made good progress refining the vision today. Really look forward to launching V1, but there’s also still a lot left to build!
Every product has a number of major “launch moments”. For example, announcing the availability of a beta version. Or launching the full version to the public. Everyone working on web apps will be familiar with launch days on Product Hunt, Hacker News, and so on. Whatever industry your product is in, there will always be a small number of large publications, events or sites you want to be mentioned on.
While these launches are a great way to make some waves, they’re just one-time events. If they are super relevant for your audience, they might result in some initial customers. That’s a great boost after all the work preparing the product and the launch. The one-time spike in traffic, and even the long tail of traffic that will follow over the course of weeks or even months, is not going to define your success however. [1]
Rather than being a spark of a magical self-sustaining reaction, it might provide some lift and push you in the right direction. To keep going you need to keep “launching”. Don’t just work towards one big launch, but think about how you can get your product in front of some people all the time.
Other than large public launches, which take a lot of preparation and time (after all, your one and only shot needs to “perfect” right?), these “mini launches” don’t need to be a lot of work. A lot of small marketing activities can add up to a lot of impact. Especially when we’re in building mode, it’s easier to carve out just a little bit of time than to have to prepare for a big marketing push.
For example, a large chunk of our current beta waiting list for Thymer came from a few small comments we posted on forums. Taking a few minutes now and then to comment at the right place (where your audience could be) and time (a bit of luck, so looking for these opportunities more often helps) has more impact than a large “marketing project” would have had at this stage.
Example of a short comment we posted while looking for relevant discussions related to the product. Just a few minutes here and there to grow our launch list with a few dozen more people.
Another advantage is that it’s completely fine for these small launches to fail. You won’t really know for sure what works very well anyway, so if it’s small tasks there’s less reason to not try them and find out right away. It’s also a lot more motivating to do many more small launches while working on a product. Working on a new product for a long time without any feedback from users is risky but can also make the eventual launch feel more like a make-or-break event, even though it shouldn’t. In our case we also do lots of “mini-launches” showing the things we’re working on on Twitter. These are really fun to do for us and they result in new people seeing the product at the same time.
Besides, launching early and often also compounds your efforts. Every mini launch builds more audience, who in turn might share things you launch later, resulting in more people seeing what you’re doing. That also increases the chance you’ll be able to pull of the larger public launches.
Another reason to keep repeating your marketing efforts is because most of the traffic or impact fades after a while. Even other channels like SEO, ads, and content marketing, which often sound like it’s a set-and-forget kind of thing, need some maintenance. Rankings will drop, content gets stale and ad keywords will become irrelevant (e.g. competitors start outbidding you). Again, that doesn’t have to mean a lot of work which will fill up your entire schedule, but it’s most effective and less time consuming to keep doing it consistently.
[1] Conversely, it’s good to remember that many of these launches have elements of a lottery or popularity contest, so not being able to “succeed” in a big public launch right from the start isn’t a reason your product isn’t successful. You’d be surprised how many #1 ProductHunt products no longer exist and how many #10 products do very well in their markets. Not every launch working out right away is another reason to always be launching of course.
We’re going to take a quick break and will be back with our daily updates on April 11th.In the meanwhile, you can find a preview of what we’re building at Thymer.com, or check out the list of all our posts or the recaps of the work so far.
From the start on Day -1, when we built this site, we added a note in our FAQ on how we would work on the 80-Day Startup. Rather than working for 80 days straight, we decided we would take breaks too. Some of the cliches about running a startup being a rollercoaster are really true, and there’s a lot of different tasks to juggle at the same time.
For our 80-Day Startup project, on any given day we can work on a combination of code, graphics/UI design, marketing, growing an audience, writing blog posts (more work than we expected to be honest!), replying emails and DMs, configuring a server or anything else that needs doing.
Next to that we’re running our existing SaaS business, with similar work as well as all the work that comes with an established product like customer support, sales, finances, content marketing and so on. Some days we wake up to new MRR because new customers signed up completely organically/passively, while we’re getting to work on cool new features. Another day there’s a tricky bug to fix, some boring task to work on, while a customer churns at the same time.
That’s all just part of the thrilling ride, and for us there are way more highs than dips, so we both really like working on all of this.
But it’s exactly because we like working on it so much that the breaks are important. When it often feels like a hobby, it’s too easy to fill up time with work, and there’s lots of other things to explore and experience too. Being in perpetual crunch mode is unhealthy, and also totally unnecessary. When we worked on our very first product, back when we were students, we also had work-weeks of 60h or 80h, next to a side job and studies, but there’s no reason to keep doing that.
As we’ve seen over the years we’ve been doing this, growing our existing business at a healthy pace is totally possible. We focus on the things that matter, stay productive, and automate a lot. That’s why we’re building a new product in exactly the same way. It’s the only way to keep running rollercoaster marathons.
Whether it’s life stuff, traveling the world or something completely different, we want to keep plenty of space for that too. And if you would worry about productivity, we can say we always return more refreshed and more productive, easily making up for the time we take breaks.
So we’re going to take a quick break now. Diederik will be on a trip. I will be away later and do a bit of work for our existing business for now.
If you’re new to the blog, you can find all the posts we’ve written so far at Topics & Days. We post a (roughly) weekly recap, so to get a quick summary of what we’ve been working on so far, you can find those at recaps.
If you’re a binge reader of the blog (thanks for following us!), this might give you some time to catch up (we noticed it’s quite a lot of posts by now ;).
Since the last recap, we’ve spent most of the time on the coding side of things again, making a lot of progress on the work on the app. All features we’re working on are the most important core features, which we really need to launch the MVP.
Especially the editor itself has a lot of moving parts. As a good editing experience is part of the unique selling proposition for Thymer, a lot of time goes into making this work just the way we want. As we learn a lot about all the bottlenecks in the app as we go, sometimes that means having to throw out some earlier work and rewrite some parts (Build one to throw away). Not an easy decision, but it’s really starting to pay off. It’s starting to get really polished in the parts where this matters for the MVP. More and more features as well as performance are starting to get to where we want it to be.
We also started work on other core features like scheduling, panel tabs, and the command palette.
A lot of time is spent on working on the MVP for the app now, but we’ll be able to work on a lot more marketing ideas as soon as we have a bit more to show. In the meanwhile we’ll keep mentioning what we’re working on in a few communities, using the landing page as a sneak preview. We’re at a bit over 100 people on the beta waiting list now, so that’s a nice start for now!
Thanks again 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 🙂
We’ve been working on a bunch more UI components the past two weeks. They’re all part of the core for the MVP for Thymer, but one thing we won’t have time to look at before the launch is making these work on smaller devices like phones.
Part of the process of building an MVP is that we inevitably have to say no to things we really care about. In our case one such aspect is starting with just one platform: the desktop (specifically the web). The first version will be unapologetically desktop-only.
The USP of Thymer is that it works like an editor/IDE. As planning and brainstorming are creative processes, we think being able to simply type, select, copy/paste and change your ideas or schedule as if it was text is a big boost in productivity.
We want to solve this one problem really well. In our case, the UI really matters. If we decide to build something for desktop, iPhones, iPads, Android watches etc etc from the get-go however, not only will we take forever to launch, but we’ll need to take shortcuts at some point to launch at all.
One such approach of building for all platforms at the same time is by building something which is mobile-first. But mobile-first is all-the-rest-last. Instead of coming up with the solution we think is best and then building that, we’ll end up shoehorning a toy UI onto the desktop just to match the constraints of a mobile device.
Of course not having a mobile app from day one is far from ideal. We all work on the road from time to time on our mobile phones. Yet a lot of the real creative work we’re building Thymer for gets done behind a laptop or something else with a keyboard and mouse/touchpad. To solve that problem really well, we think it’s worth delaying some sort of solution to work on a mobile for a while.
So we have the choice: hack something mediocre together for the launch as quickly as possible that works on all platforms, but is perfect for none. Or build exactly what we envision, but start with one platform.
Some of the components we’ve worked on the last two weeks: panels and a command palette. UI components we think will be super productive on desktop.
These choices are hard to make when you need to decide what to launch with. In the end it’s better to start with making something smaller in scope but which you think is really great. We need those initial fans who really like the solution we’re building to get off the ground. With some cross-platform responsive app approach we can’t build the kind of editor we want, and it will just look like all the rest.
Once we know people really like the concept, we can look into options to make it easier to work on the road. Because of the way the app works in the backend, it will be quite easy to add offline support so it’s no problem to keep working on your laptop on a long flight. As for mobile, we’ll still have to look into that later.
Because we want to create the best experience we can for desktop without the constraints of it needing to work on mobile, it will most likely be a completely separate app (although we can reuse the API/backend of course). That way we can design the other way around, too: come up with the best possible user interface controls for mobile, without having to stick to desktop concepts. Plus this might make it easier for us to outsource work on the app for a specific platform if we want to go that route.
We also kind of like the idea of a “companion app”. A smaller version specifically designed for mobile use. Rather than cloning every exact feature from the desktop version for mobile, we add just the things you might need most on the road and make those very easy to use. Like looking something up or quickly jotting a thought down which you can then work on once you’re in front of a laptop again.
But all of that is for later. We first want to focus on building something great for just one platform and see if people like the idea in the first place.
When comparing products or services, one important factor in choosing which solution to go for is trust. We know we are looking for certain trust signals before buying services as consumers ourselves, so we need to make sure that as makers we address those same questions and concerns too!
This is especially true for the kind of product we’re building. It’s not hard to come up with concerns potential customers might have. With any SaaS product you want to know it will remain online, your data is secure, people care about your privacy, and so on. Especially when trying out a new product from a new startup, you want to make sure it sticks around.
The “close tab” button is your biggest enemy, and just the tiniest concern you don’t address can cause people to not even give it a try. As I wrote before, people are going to look for answers to these concerns anyway. So you can either address them yourself, or people will leave your site, look for answers on sites you don’t control (and maybe come back, who knows). You might think people will take the effort to email you if they need an answer, but it’s much easier to “close tab” and look for something else.
Luckily, addressing most of these signals really don’t cost a lot of time:
About page
This seems too obvious to even list here, but just really, just mention something about you or your team somewhere. When launching your MVP, you really don’t need to publish a complete biography. Even something like a link to your Twitter profile will be enough. Software is so anonymous, and is literally written by folks on laptops on different sides of the planet these days. People like to not just buy something, but from someone (especially for B2B, buying something when it says just [email protected] in the footer is going to be a harder sale).
Social media/online presence
This is actually a mistake we’ve made for our first product. We noticed that when we didn’t have an easy way for people to find recent activity about us online, they seemed worried about the product being abandoned. I don’t have sufficient data for this to claim any statistical significance, but whenever we didn’t tweet for a while on our company twitter (which we link to in the footer of the product’s website), it seemed like we somehow converted less people.
We even had people contact us asking if the product was abandoned, because they couldn’t find updates (on our Twitter or other social media, probably). And this was just after we had completely redesigned the product a few months before and we were very happy with how polished the product was now. Ouch. But it makes sense in a way, people have probably been burned before by some startup with poor support, so it’s just another trust signal.
Fast support
We always aim to answer any support emails really quickly. This is related to software being very anonymous, and it just shows there are actual humans involved and that we really care (and good support is a USP too!)
Security/privacy policy & GDPR
Especially with SaaS products, you want to make sure customers can see you care about their data. More than anything, these just show you’ve put thought in it at all. And next to it being the right thing to do, some things are simply required, for example GDPR compliance.
This is probably a topic for another post, but especially when launching your very first version to validate an idea, it doesn’t need to be anything super complicated. It already helps a lot to have a nice FAQ-style page to address the biggest concerns. How will you handle cancelations, data erasure, data export, how do you store your data and so on.
Better than trust
Speaking of security, ideally you wouldn’t need to trust a company much at all. In the case of Thymer for example, we would really like to look into end-to-end encryption (E2EE) at some point. We will launch with encryption in transit and encryption at rest from the start, but I don’t think we’ll have time for E2EE in our very first version. We can’t build everything at once, but it’s good to think about which features can address the largest concerns for not signing up first.
Testimonials
This isn’t possible on day 0 with zero users, but as soon as you have some users, ask them how they like the product and whether you can add their reply to your website. Related to this, one of the things people will usually look for is reviews for your product. Make sure you reply in those places when people have questions. You can even create your own “X reviews” page and rank for that, so you can guide people to different reviews and include your own support structures when they have questions.
Bugs
Every product is going to have some bugs and glitches, that’s hard to avoid. Some bugs are so embarrassing however, it just signals you don’t care at all. Of course you won’t have infinite resources to make everything perfect, but prioritize fixing critical flaws. Some bugs there’s just no coming back from. Fix it or people will stop trusting your product.
I got reminded of wanting to write this post because it’s that time of the year again here, where we have to prepare and file our business tax reports. This is something which always used to cost a lot of time and money, and I just happend to notice others in my Twitter timeline joking they wouldn’t be able to get any real work done the next two weeks because they had to work on this.
We try to automate all our processes as much as possible. For many tasks, instead of being a team of a two, we try to be more like a team of two plus a dozen of little scripts/bots. By automating things like invoicing, server monitoring, and yes, even things like accounting, we’ve managed to cut overhead significantly. That way we can just focus on product and customers, which made it easier to scale without the need to hire as fast as other similar companies.
In this case, dealing with accounting/filing taxes is a perfect example of how we automate things. Even with having thousands of transactions to keep track of for our existing product, the entire process took half a day. And the only reason it takes half a day is because our government doesn’t offer an API to avoid having to manually enter the data into their forms. [1]
Obviously this isn’t an option for everyone. It helps we can create these scripts ourselves and that we can vertically integrate all our systems this way (although a lot more nocode options are available these days, too). Perhaps we take automation a bit too far at times, but I also don’t agree with the other extreme of “outsourcing everything”.
The popular advice goes along the lines of “you should always outsource X, because it’s not core to your business”. The problem with that is that the process to run an effective business is a core feature too. It’s an internal product, which can really give you an edge if you can operate faster and more efficiently. It’s the product that builds the product.
Accounting and filing taxes has absolutely nothing to do with our core business. And yet, by automating this ourselves, and making it part of our “business stack”, we’ve saved a lot of time and money which we could spend on our products instead.
We almost always start out with a process being completely manual. For example, when we launched our first product, we couldn’t even bill customers yet! And because Stripe wasn’t a thing yet, we had to manually charge customers every single month. For that stage of the product, it was the right amount of automation though: we had no idea if it would take off, and the manual process was still manageable for those initial customers. Our priority was validating if we could get customers in the first place.
As the product grew, we automated billing and charging for subscriptions. Invoices would be generated automatically, sent out to customers and saved to our database. We even automated keeping track of different currencies, VAT rates and so on. Then the business grew even more, and we got larger business customers who wanted to pay by wire transfers, outside our automated credit card system. And of course by this time we also had other software/hosting vendors from all over the world where we got invoices from.
All in all, when it came to our accounting, we had this large .zip file with all invoices, but there was no automated balance sheet, list of ledger accounts or journal combining all these transactions. Every year we had to spend a week or more unifying everything from bank and credit card statements, Stripe invoices, vendor invoices, salaries and much more into a neat double-entry bookkeeping Excel file.
When your work gets replaced by a Python script
Obviously, we didn’t have time for this, so we tried outsourcing first. It was a total disaster. Long story short: accountants over here do everything manually (which is absurd when even small indie companies can have have thousands of recurring subscription transactions), don’t understand SaaS, don’t understand selling internationally, or much of what we need at all. We even tried a very expensive large accountant firm. Same story. Everything they did was manual, full of mistakes, and they even managed to not file a bunch of critical reports at all. In the end we spent even more time, having to verify and fix their work on top (if you’re an accountant reading this with an interest in startups: our market could use an “accountant for SaaS” product). All this to say, that this is the part where I think it’s too easy to think outsourcing will fix all your issues: much of what gets outsourced just won’t get checked/verified. It will most likely be full of mistakes, and that has costs too.
In our case, the cost of mistakes and pain of not making this process part of our business stack was larger than the one-time cost of automating it. So we automated the whole thing with a bunch of Python code, and named the program after the accounting firm we thankfully no longer needed. John.py – not their real name 🙂 – is now part of the product that is our business, is integrated with all our systems, and takes care of all the accounting. From handling bank statements, to invoices to generating balance sheets and fiscal reports. And because we assert everything, it is correct down to the cent. It costs $0 per year.
We’ve been able to postpone a hire and spend time on interesting features for our customers by automating this completely. Perhaps automating accounting makes absolutely no sense in your case, but there will likely be other parts which, when considering your business as a product which can have moats of its own, are better to integrate and automate than outsource.
[1] I think there is some way to partner with the local tax office if you’re an accredited accounting software vendor to get access somehow. We’re so allergic to manual processes that I must admit it’s very tempting to apply to become one just for the single purpose so we can file our own taxes quicker, although that’s probably a real waste of time 😉
However interesting that might be for us, it’s important to not get carried away too much when it comes to actually building the product. It’s great to have a vision of where things could go and explore those a bit, but we need to keep the first version small. It’s not easy saying no, especially to your own ideas. Working on whatever you want is a big reason to run a business in the first place, but to increase the chances of success, the order in which you work on something matters.
The type of ideas we like to work on is where the long term vision of a product is sufficiently large, but where the very core, the smallest possible version, is very small (although very small is relative depending on the stage of your company of course). Working on something which could potentially be used by many many users all over the world makes the problem that more interesting to work on for us. But if we want to start up and grow, especially as a bootstrapped business, we need to be able to build the first version quickly.
Thymer is a good fit for us with these requirements. If we manage to get traction and get to the point of lift off, it’s easy to see how we could keep developing the product into a larger vision. Because it’s a very horizontal product, a feature like plugins alone could grow it into a platform, to become a control center of sorts for managing everything you need to work on or organize in your life.
At the same time, the core vision is really easy to describe: an IDE, but for planning/tasks. This alone is plenty of work, so we’re building just the (polished) parts which convey the core of that vision. That this core vision is oddly specific (many people will have no idea what an IDE is) is a good thing. It might be tempting to think building “project management software” is a better idea because it’s a huge market, but it’s very vague, has endless scope, doesn’t offer ways to reach any audience in particular, and there’s nothing unique about it. You can’t launch with a generic “platform” on day 1.
In the beginning you need the focus: reduce the scope on the product side so you can launch faster, and find a niche on the market side to find initial fans.
Building a huge product for everyone from day 1 makes it incredibly hard to succeed. In terms of marketing, paradoxically, if the product is for more people (everyone!), the less people will care. It’s just not exciting for anyone in particular, so it’s harder to reach initial passionate users that way. Plus, building up any kind of momentum takes time. If you spend years building, it needs to be an overnight success on the day you launch because you’re out of time. That’s a huge gamble. Instead, always be launching. When launching something small first and then building more on top while it’s already out there, you can do the momentum building and product building in parallel. There will be many more “launches” this way to generate some renewed interest with every add-on or new development.
Even companies with larger goals have a “secret master plan”, i.e. get to a smaller goal first
On the building side, if you only keep building, you will eventually run out of runway. Even with a large runway, the longer it’s going to take, there’s a chance you’ll simply run out of motivation. And as long as you’re building in the proverbial basement, you don’t train your launching muscle. It’s easy to get bogged down in details which don’t matter that way and drift further and further from the shores of actual user/customerland. You also don’t get any feedback, so by the time you get new insights from initial users, it might be too late to course-correct.
Another risk is that by the time your “perfect” product is finally finished, it’s obsolete, and you need even more time to make it “perfect” again. That’s not to say you need to go on some death march either, or stress out about being the fastest and worry about competition all the time. There’s usually plenty of time, but markets and trends do move on eventually, so taking too long does have risk. All in all, the chance you will really launch something successful in the end will go down.
And yes, we all know some counter-examples of products being built over the course of years to become an instant hit. But that’s a lottery, and you don’t know all the many examples where it didn’t work, where launching that way failed, and the movie/book about its story was simply never written.
Next to the approach for building a single product, this also applies to what ideas to work on. In other words, it’s easier to build Zip2 first before you start SpaceX. Start small, keep it simple, grow from there.
@wcools
