19 ms·

20 months, 2K hours, 200K € lost. A story about resilience and sunk cost fallacy

333 points by dSebastien 6y ago

soneca 6y ago
> ” Between July and September, I worked on different things: the build system, Docker/docker-compose, continuous integration, authentication, internationalization, etc.” Authentication seems to be the only thing the author should be working on at all for a MVP. And even so, I would personally choose AWS Cognito or something like that. From reading this, it seems to me that the issue is a mix of harmful obsession code quality and bad priorization of what to work on. Probably some feature creep too, even with the author claiming they cut all to the basics.
- javajosh 6y ago
  Yes, its interesting from that list of things he did for 2 months one cannot discern what his project was!
  - bombcar 6y ago
    Spending time reading horror stories on HN can lead to a form of paralysis. While it’s true bad decisions can be made at any level and anytime early on it is much more important to get something (anything) up and running - even if you scrap it later.
- leesalminen 6y ago
  Just finished a MVP idea I had and used Firebase for everything, including auth. Auth took a total of 15 minutes to work into my react SPA. Called it a day and moved on feeling very impressed with Firebase.
  - nmfisher 6y ago
    I'll reiterate what I said the last time it came up on HN - this is exactly why I use Firebase, and why OP probably should have done the same. It's literally 15 minutes to configure/integrate, and you're done. You can then move on to building/iterating on actual features that matter to customers. Until you've proved you're building something that people want to buy, your data layer only needs to do the absolute bare minimum (store some data). It doesn't matter if it's not scaleable, performant, extensible, etc. 99.9% of the risk is that you fail because you're not building the right thing, not that you fail because Firebase wasn't appropriate. You have a limited number of hours in every day, and they are much better spent building features side-by-side with customers. You won't even know that Firebase is a bottleneck unless/until your platform is successful, and at that point you're in a good position to migrate/rewrite/whatever. A couple of commenters smugly pointed out that they were contracted to fix Firebase issues later down the track, and that's why they would stay away from Firebase in the first instance. First up, there's clear survivorship bias there - the fact is these businesses survived and were in a position to hire someone to upgrade their data layer. That's meaningful in and of itself. Second, don't pay too much attention to people who have never bootstrapped anything from the ground-up. What works in a mature, stable, well-funded organization is not what works in a solo, early-stage startup that's strapped for cash, time and equipment.
    - nicoburns 6y ago
      Setting up postgres on heroku is similarly quick and straightforward, also comes with a free plan for when you're just starting out, and won't leave you with the headaches you'll almost certainly have later with firebase. Firebase is slower to iterate on, because you have to bake your query patterns into the schema (yes your data still has a schema even if you don't have to define it up front) Using firebase for auth and/object storage makes sense. But I don't understand why anybody would choose to use the database(s) except for a few niches where realtime is critically important and query flexibility / data integrity aren't.
      - nmfisher 6y ago
        1) Firebase storage has the advantage of one-click integration with auth (Google Auth, Sign in with Apple, etc). Probably not difficult to achieve with Postgres on Heroku, but why waste a couple of hours on something when I don't need to? 2) My golden rule is to avoid anything that doesn't get you closer to a customer in the next 14-28 days. For some use cases, Postgres on Heroku might help you do that. For me (see next point), it's just adding another platform/service for no reason. That will only slow me down. 3) I disagree that "Firebase is slower to iterate because the schema is implicit" (at least, as a hard-and-fast rule). It depends on how complex the schema is. You iterate on implicit schemas by rewriting code, and you iterate on explicit schemas by rewriting code and the schema itself. This is faster for complex data models with strong integrity requirements, but for basic data models (think mobile game leaderboards, etc) it's just unnecessary. That's not to say that any of this is a huge amount of extra work. I'm sure a lot of people are reading this and thinking "Postgres will just take an afternoon to hook up, why not?". The reason is that spending that afternoon with a user is infinitely more valuable than spending it hooking up Postgres. You have to be ruthlessly focused on what moves you forward, which at an early stage is simple - features, customers, users. On any given day, there are literally hundreds of things you could do that "will just take an afternoon". If you allow them to distract you, you'll probably end up like OP - 2 years in with a well-architected system that doesn't have any customers.
        nicoburns 6y ago
echelon 6y ago
Medium hellscape. They now require an account to read.
- hydroxideOH- 6y ago
  Open a private window and read it in there.
  - echelon 6y ago
    My criticism is that we've gone from an open Internet to one where every silo wants us to log in. I hate this system. Medium doesn't write any of these articles and they think their value add or marketplace or whatever it is that they've built is in exchanging content for personal information. I'm sick of post-2006 Internet and I want things to go back as they were.
JamesBarney 6y ago
Before I riff on him a little, I'm very thankful the author shared his experience, that takes a lot of bravery. He's also not the only person to make this mistake, so many have. I learned a lot of these lessons from making a bunch of expensive bone headed decisions myself. I also am not implying that just because he fundamentally doesn't understand an MVP or how to build a lean startup that he isn't an awesome dev, I honestly bet he is a great dev who just learned a valuable lesson(3 times :| ) about what an MVP truly means. ( I haven't shared them because I'm awful writer, but I hope to one day ) But wow does this guy not understand an MVP or what matters for a startup. > I became more and more “aggressive” about reducing the scope and focusing on the essentials You should do this day one before you write a line of code. There should be nothing you can cut from your MVP. For the first two months of my last MVP to edit data you sent an e-mail to a dev who wrote a sql script that edited it for you. We still added 3k MRR each month. For every feature you should ask "What would happen if I cut this out?" if the answer is anything but "It literally wouldn't work for any individual who could conceivably use this product (with a broad definition of conceivable) then the answer is cut it. Is it a differentiator? cut it. Does your product suck without it? cut it. You can always trade time for features, but you can never trade features for time. > Maybe I obsess too much about code quality The answer is YES YOU DO! Code quality doesn't matter. It really doesn't matter. What killed your first three startups? Was it code quality? Or was it was not getting out a product fast enough, not iterating quickly enough, and not finding product market fit fast enough. This experience is typical. If the code quality on your MVP doesn't physically disgust you, you're probably focusing on code quality too much.
- BobbyJo 6y ago
  It's funny how different peoples' experiences can be. I personally witnessed one of the two startups I worked for fail as a result of code quality. Things ended up being too slow and error prone for some of our customers, and eventually they left us behind. We tried to attract new customers, we had amazing feature set after all, but the performance/stability hole ended up being too big to dig ourselves out of before we ran out of money. I agree that the poster likely focused too much on it, but it's definitely not something you can ignore completely with the assumption you'll always have extra time later to go back and fix things.
vessenes 6y ago
This is a hard read for me, because I can sense the vision and determination behind the last two years, but there has been some really poor decision making as well. Here are some things that come to mind reading this: * Most people are not cut out for startups, and I would include some of the people you've recruited along the way, by your description. It's hard enough to get a startup off the ground without having semi-motivated partners. I think you do need a partner or two, but I wouldn't say you have been brutally honest about what exactly you need to be successful yet. * This is partly a Europe / West coast US thing, but one thing Silicon Valley does well is create a solid revolving door for entrepreneur types -- in general, if you want to go try a startup, go for it -- even if you fail, ideally, you will learn some new skills not on the big company's dime, and come back more seasoned and ready for another round with the big co. I know this is harder to pull off culturally in Europe, but I think some of the paths toward successfully pulling this off involve selling your experience harder, (along with getting broader experience). If you're depressed with a year of failure, you will feel like you're slinking back. By comparison, I would hold out examples of one of the moviepass founders who bemusedly reports in interviews he's in demand for a follow-on startup, despite launching a massive massive crash and burn startup. And it's right that he's in demand; he got a startup launched with huge scale, brilliant free press and marketing, and briefly shook up an industry. I bet he'll be back. Which leads me to point three. * You have picked terrible, terrible markets. Tiny markets. Markets which require public tenders. In tiny countries. Markets where purchase decisions are made nearly infinitely far from those who require the benefits of the purchases. Seriously, these were terrible decisions. You compounded them by not getting some initial sales done first. I imagine that as you read this, right now you have roughly ten reasons why your path made sense at the time. And, I bet it did make sense at the time. But it was the wrong path. If you want US west coast philosophy, I can say that some of the best incubators on the west coast consider maybe their number one core skill market testing -- they work very, very hard at testing out if a product will sell before they write a single line of code for it. To the point that places like Pioneer Square labs are actually turning their product-fit test facilities into SAAS model products in their own right. If you prefer value investing, Buffet's aphorism is helpful here: it's better to be mediocre at a great business than it is to be great at a mediocre business. You could be a brilliant, brilliant coder and a brilliant, brilliant product person, but it just won't matter if you are selling something nobody wants to people with no money. At any rate, my personal advice to you is to listen to your urge to be an entrepreneur, and set your sights both much higher and also much more narrow. Pick a giant market that you care about, pick a niche you can do some damage in, get some test sales in the door, and I think you'll find you feel a lot more successful, and it will paradoxically be less emotional work. If you can get a little success that can help aim your company as you iterate. Also, it's hard work to write your retrospective, thanks for doing it -- I hope you find some success, and can update so your readers get a feel for what to do on their own paths. In summary, product-market fit is the only thing, and you should get it before you do anything else. If you sell crack cocaine, the world will beat a path to your door. Crack cocaine I've seen this year come across my VC fund's desk: * paramutual insurance (merchants want it, customers want it, it's cheap to provide). * product authentication which works from factory to distribution to retail to end customer (manufacturers really really want and need this and can convince customers it's in their best interests) * defi lending (people want to borrow on their crypto, and want 0 friction to do so) * Instant vendor network credit scoring as the real value add for supply chain management - large cos want insight into their vendor world and early warning of problems, small vendors desperately want cheap financing * high margin trading volatility of all sorts - people love to gamble * home insurance bought by app -- nobody wants an insurance agent, or spammy calls. Most of these could have their own niche spins, but the point I hope to make is that there is a wide world out there of problems, each of the above are giant markets, with plenty of room to be 'mediocre' and still have happy customers, and generate huge wealth. Best of luck in 2021!
jokethrowaway 6y ago
That was an amazing read! Thanks for sharing your experience. The obvious feedback is to let go of perfectionism and ship a real mvp. If you're spending 2 years on it, it's not a mvp. Before jumping on a new idea, I'd suggest to think how you're going to sell it and test the market by talking to people in it. Getting better at finding cofounders (as in, cofounders who would think about these problems while you build the product) would be good as well. Personally, I gave up on that last one and I'll just fly solo and smaller, but you may be more optimistic. Also I'd recommend you to pick something smaller and easier to sell. A generic B2B SaaS API to solve a small problem can help you build a passive revenue stream and free you from worrying about money and plan bigger, better, more interesting projects. Funnily enough, during uni I made an app which was making a decent amount of money in advertising (netting everyday a daily rate of a mid developer contractor rate in London) but didn't have a future. I decided to start a company doing something bigger and better and failed miserably. Some contracting, some more working and a few kids later, I'm back at square one building more small passive revenue streams. Look up Pieter Levels's presentation Bootstrapping Side Projects into Profitable Startups.
10x-dev 6y ago
Great read. Thanks for sharing! I too think your definition of MVP needs to be adjusted. It sounds to me like an excited user came up with the MVP feature list, not an experienced developer, like "it's gotta have rich text editing capability and pdf export and offline support and nice ui!" because how can you not highlight important notes in bold and download your notes later, right? And it's got to be pretty to look at, and obviously needs to work offline when the wi-fi is down, right? No, wrong. Everybody I know gets dreamy at first. It's your job to bring people down to earth. Simple text editing at best, and I do mean 'at best'. Basic UI, online only, unsexy solution. If you can't sell that, then you are either not solving the right problem, or it's just not that big of a problem to begin with. Kubernetes, and Docker and CI? Cool tech, I suppose, but time wasters. Your release process should be scp-ing and extracting a zip file on the prod machine, or git checkout the files. The one thing that went right was sticking with Couchbase imo. The world is filled with people who regret rewriting the persistence layer for an MVP under pressure. I am one of them. Several times over. Do not doubt the decision. It was the right choice. Finally, schools and restaurants don't have money for software. I know folks who wrote school software. It was a travesty - the government gets involved at a certain point and wastes your time, the school budgets are razor thin and will not throw money at you. Restaurants are usually low tech as well. Most pay only for basic websites. Find markets with deeper pockets.
- sfeng 6y ago
  For the record, I've used CouchDB multiple times and it was a mistake every one of them. Moving to Postgres never takes as much time as you'd think, and having a database which is rock solid, understood, and performant is a great idea. Choose a DB which you will be happy with when there's an issue at 4AM, not the one fun to use at 4PM.
  - j45 6y ago
    There is no small amount of time wasted taking data from non relational dbs and making it relational. If you prefer nosql, consider something like Hasura which reveals a graph on top of a Postgres dB. I’m not affiliated with either but it’s important to not make tech decisions based on what a developer hears others like to use.
wiradikusuma 6y ago
It hits home with me, and the TL;DR is: Don't bother setting up "proper" DevOps (but you still need it, just to get going), Don't bother building for scale, Don't bother proper code lifecycle... Until you have some traction. Focus on your MVP. Your truly scrappy MVP. Applicable most (only?) when there's only 1-2 tech guy. More than that, you need some structure (communication issues). Technical debt? Yes. Server will crash with angry customers? Definitely. Will never experience those problems because you product will fail anyway? Most likely. Also, refrain yourself from using that latest JS framework. Use what you know like the back of your hand.
- redis_mlc 6y ago
  Just to expand on this: > Don't bother setting up "proper" DevOps (but you still need it, just to get going) Correct, you can use a Makefile or make.sh for years, more to remind you of the build process rather than something that needs to be continuously run, in a startup. Time waiting for a build process is time not adding user features. > Don't bother building for scale Correct, since finding the true requirements for scale requires having many users, and the unicorns that you admire had multiple rounds of scale-out rewrites. (You can add Google Analytics to your pages to see their usage. I've seen some companies do this as a lightweight interim APM before. Pages that nobody uses aren't a bottleneck.) My current SaaS app has a built-in APM using pre-auth, post-auth and post-load hooks that I added after version 2.0. I learned the auth was slow, but the page generation was fine, so I fixed the auth routine. > Don't bother proper code lifecycle Correct, since you don't know what the final version will even look like. The exception is if you've done similar projects with a similar expected load, then you can skip a lot of the steps that didn't work before. My goal is to write code to Open Source standards, but I realize that rework will be needed later for scale, etc.
irjustin 6y ago
Thank so much for writing this. The detail, the hurt, pain, everything. It's super real and the experience is not for the feint of heart. Please stop coding. Go find a paying customer. Whatever it takes. Lots of the other comments echo this sentiment, and you already know this in your bones. The problem us engineers face is we tend to hate sales. Whether we're bad at it, hate the experience, or insert X reason... we avoid it like the plague. At least I do. And so we support the organization by being the best damn engineer we can. Features features features. But there are times when that isn't the answer. This is one of those. It's Monday, the day you work on the SaaS - pick up the phone and make calls. You're not an engineer - you're a founder.
- ku-man 6y ago
  Unlike the US, in Belgium software developers don't call themselves engineers... unless they are actual engineers. So, careful with the titles.
issa 6y ago
I think the main lesson here is that an MVP has to be small enough to be completed in a reasonable time. Even if it means boiling the product down to one single thing. Everything else can wait.
- dSebastien 6y ago
  Clearly! Haha ;-)
trestenhortz 6y ago
That’s a great story and I can really feel his pain.
deleted 6y ago
[deleted]
jy2947 6y ago
Thanks for sharing! I also wonder whether the OP should have made clear decision (and expectation) between bootstraping vs startup, because I think they require different mentality, operation style and even market. With startup he and his cofounders could focus on applying incubator and/or angel investors early on. They would get some feedback on their ideas. They could even get a little funding to hire a designer or contractor to help build the UI (which appears to be the big drag). In this case you are trading ownership to additional support systems. If you do bootstrapping, then you'd need to prepare for the longer timeframe, and financial burden. Maybe still keep the original full-time job and working par-time on the side project.
ricc 6y ago
I personally have a very simple takeaway: Never half-ass two (or more) things. Always whole-ass one thing. I think the OP was not prepared to completely dive in to his startup project which led to distractions, i.e. side business and writing, thus compromising dev time, mental recovery time, and eventually morale.
- adrianmsmith 6y ago
  Bill Gates and Warren Buffet famously stated the key to their successes had been “focus”, i.e. going all-in on one thing.
tmikaeld 6y ago
"I became more and more “aggressive” about reducing the scope and focusing on the essentials; still, I didn’t want to forget about code quality." After reading all of it, it seems to me that the problem is right there. Security, maintainability, offline-first, horizontal scaling etc. Should have just thrown these out the door and put every client on their own VM, with local database and automate backups and updates. You'd get something out the door and could make sales, then re-factor for the next iteration of the app. You'd be hard-pressed to find any client that wouldn't be sufficiently sustained on their dedicated hardware (or VM).
- grumple 6y ago
  VM for a mobile app?
  - tmikaeld 6y ago
    Absolutely, highly scalable VMs are available for less than 2€/mo from providers like Hetzner and OVH (less at scale), with an included "global" redundant network. Does it make sense if your business idea is having thousands of customers on a single VM by using containers? No, of course not! But it does make sense if each customer is worth more than 2€ per month.
    - XCSme 6y ago
      I think this is what's wrong with today's SaaS and web environment. People thing that by going with AWS, creating a complicated auto-scaling infrastructure that supports billions of user is the way to go and the most cost-effective way, but while doing so many forget that using the simpler solution that costs a bit more can actually save time and money. What's the point of trying to save $1/month per user if you have no users yet and achieving this cost reduction takes one or two more years of development time.
      - jokethrowaway 6y ago
        AWS is rarely cheaper than competitors. It just offers more for more.
kureikain 6y ago
Reading this I realized the same mistake that I made. It's because we focus on a product that 1. need lot of front-end works 2. target a user-base that need a lot of onboarding I have a side project that I worked on in 10 years and still doing nothing...Its scope is too big and because It requires some kind of front-end works, which isn't my strong suite, it becomes a constant battle to say what should I do, how should I make UI/UX intuitive. Then after I sitting down after 10 years(and still have nothing to show), I leanrn about 1) and 2). Then I think in order for me to move forward when I have a day job, I have to focus on something that require zero or very little front-end works and can easily self onboarding. I did that idea. And something I think I can finished in 2 weeks ended up taking me 3 months and still not 100% polished but at least I have finally launch it and have my first paid customers So my advice to anyone is to find something that requires minimal front-end works can can easily on-board new users. --- the service is https://hanami.run https://hanami.run an email forwarding service if you are curious
lonbigtech 6y ago
How much of that 2000 hour was spent on the core experience, the meetings screen? How much of the work that wasn’t spent on the meetings screen had to be reworked due to changes with the meeting screen? How many times has the meetings screen been shown to prospective customers?
- dSebastien 6y ago
  On my end, probably 50%. I've logged ~200 hours on that screen and the surrounding components. But I get your point; that should've been almost the only focus. I did was time with tech, build, code quality, release automation, ci, code formatting, git workflows, project organization, lazy loading, and whatnot. It all adds up and eats time that I didn't realize I didn't have to spend in the first place.
baby 6y ago
If I may, it seems like you’re doing too many things at once, and yes the context switch is a killer.
ruvis 6y ago
> but the people we discussed with weren’t interested at the time; they were scared of traceability and preferred to be able to avoid taxes (no kidding :p). I'm a project manager in construction, and I still have to make my quotes in excel or word because of this. Don't know if this is a typical belgian thing, but it's pretty ridiculous.
trestenhortz 6y ago
When building an MVP stop flouncing around with your professional software development. Build the damn thing and get it launched. Every singe dollar you waste on CICD Docker and testing sends you closer to the clock running out and failure.
- dSebastien 6y ago
  Indeed. But as a newbie, you first need to start feeling that the clock is really ticking. And fast. I think that during the first year, I just had no pressure at all. I worked very seriously, but didn't feel external pressure. I had just put enough money aside, I was glad to finally work on my own terms, etc. And thus I thought it was all okay, and that our pace was normal, given the time constraints that we had. Now I see clearly how much of a fool I was.. ;-)
didip 6y ago
Heh, I totally did the restaurant platform and just like him it failed because all of the customers run razor margin business and some of them are still uncomfortable with the internet. But unlike him, I noticed the downward trends and decided to cut the losses even though I had managed to hit the break even line. I thought it was a pretty good decision on my part.
fruty 6y ago
Hi, long time tech startup CTO and CTO freelancer here. First of all, thanks for sharing your story. I think the real lessons here is that: - a founder CTO needs to be very strong on product: I never accept offline capabilities or even mobile compatibility for a MVP, this is simply never necessary to get the needed early feedback - as a tech startup cofounder, your infra should be a docker-compose.yml and that's it, your CI should be a README "ssh, git pull, docker-compose stop, build, up" and it should take max 3-4 hours to set up - caring about unit tests and the like is useless when you're still iterating fast, automated tests are good once the product is stabilized and you want to kinda "freeze" it or at least stabilize it and introduce some friction in the dev process to prevent regressions (you trade speed for quality) Sounds to me you spent entire months working on things which did not provide any business value
- dSebastien 6y ago
  You're right, thanks for the advice!
- corytheboyd 6y ago
  Agree on all points made here, though I haven’t yet been in the founding position myself.. yet :) Relevant side note: Docker compose is SUCH a nice tool for this type of work. It is very worth learning, but learning it takes time. Be careful not to confuse “we need to move fast” with “there is no time to learn how to properly use tools”. It’s worth understanding. You will have both initial nimbleness and something that isn’t far off from production ready. To be completely honest, I am still in the active learning phase with both Docker and Compose, but it’s helped keep me organized already.
- OJFord 6y ago
  'CTO freelancer'? How does that work?
  - radihuq 6y ago
    Fractional CTO I think
edrobap 6y ago
> Early in 2018, after having worked for 10+ years as an employee, office politics got to me and I was tired of wasting time in meetings. I really wanted to quit, be my own boss, and have more impact on the world around me. In a lot of failure stories, I have seen similar starts. Entrepreneurs wanting to be their own bosses and hoping that they will stumble on to a problem that will change the world. If you don't have a problem already, it's a brute force approach that takes a lot of resources including your health. I believe one should always start with a problem. Secondly, being "my own boss" is really impossible if you are working on real and hard problems that succeed. Oftentimes, your customer is your boss. To solve for motivation, you need to give sufficient autonomy and ownership to your team.
ReDeiPirati 6y ago
> I feel almost ashamed when I think about how little we have to show for it. Maybe it’s normal, maybe it isn’t. I had the same feeling, and a very similar story, when I failed for the first time. The main problem here is the process (outcome of a 10yo developer mindset in an established company): too much focus on things that don't matter at that stage. Launching a MVP, and more in general starting a startup, is all about risk mitigation and more importantly simplicity. I saw too much commitment in building and not enough on validating (especially for value that is the first big risk to mitigate).
blunte 6y ago
This doesn't help TFA, but building a successful business is usually really difficult (based on what has been seen and written about other successful businesses). Also, many entrepreneurs fail multiple times before succeeding at a business. Indeed, sometimes luck is against you. COVID was probably not on most people's risk models, so who would know it was a bad time to start most businesses? And while sunk cost fallacy is a real problem, I suspect that some terminations with that excuse might have been successes if pursued further. But having a family and children is a significant priority conflict with being an entrepreneur, so I certainly don't judge the TFA. But likewise I don't think I would use the sunk cost expression.
- valentinu 6y ago
  I second your opinion about having a family to support will conflict with being an entrepreneur. It reminds me about the reason #9 not to start a company: http://www.paulgraham.com/notnot.html http://www.paulgraham.com/notnot.html > I wouldn't advise anyone with a family to start a startup. I'm not saying it's a bad idea, just that I don't want to take responsibility for advising it. I'm willing to take responsibility for telling 22 year olds to start startups. So what if they fail? They'll learn a lot, and that job at Microsoft will still be waiting for them if they need it. But I'm not prepared to cross moms. > What you can do, if you have a family and want to start a startup, is start a consulting business you can then gradually turn into a product business. Empirically the chances of pulling that off seem very small. You're never going to produce Google this way. But at least you'll never be without an income. > Another way to decrease the risk is to join an existing startup instead of starting your own. Being one of the first employees of a startup is a lot like being a founder, in both the good ways and the bad. You'll be roughly 1/n^2 founder, where n is your employee number. > As with the question of cofounders, the real lesson here is to start startups when you're young.
WJW 6y ago
While I enjoyed the read, I was perplexed by the author writing a long post about how busy and stressed he is and then casually mentioning that he also started a new book and inviting us to sign up for his newsletter right at the end. Stop letting all your plan Bs distract from your plan A mate.
- dSebastien 6y ago
  It's just the usual end of post that I use. I've been blogging for quite some time already; more as a relaxing activity than anything; I do like sharing what I learn about. I do try to monetize what I write, but it won't make me rich anyways ^^. The book doesn't distract me from the startup project; it's just another project, to which I dedicate two evenings a week and a few hours during the week-end. It's important to me for other reasons; mostly the will to share what I do know about, and the need to think about something else. I couldn't work on the startup project also during those evenings/week-ends. I don't want to be in burnout state just because I was able to pour in more hours each week. Question of equilibrium. Maybe I would've done that ten years ago, but not today.
  - dSebastien 6y ago
    Regarding the stress, I manage to isolate things in my life well enough to keep going; otherwise I'd already be crawling in my bed crying ;-) I'm still employed, have no worries about my capacity to find a new job should everything else fail, and my family hasn't been hurt too badly by Covid so far. So I can't complain. I'm stressed about the project and where I'm going, but not about life in general. I still have tons of energy, motivation, will, and projects :)
ChrisMarshallNY 6y ago
Thanks for an honest, forthright chronicle. I wish you luck, going forward. For myself, after leaving the corporation that I had been at for 27 years, I rapidly discovered that no one wants to work with older folks; regardless of our skill level, so I went on an odyssey of self-actualization that played out a lot like what the OP described. I hadn’t sunk as much cost, and was realistic that I’d need to try out a lot of stuff before hitting my stride. I think that helps with the morale/motivation stuff. I also consulted a couple of cranky old men, with cynical views, and quite a few scars. It was humbling, but their clear-eyed judgment of my [scant] chances helped me to make some massive course changes, early on. I spent about seven months, a couple of years ago, developing a powerful, high-quality backend server that was never really meant to be used[0]. It was more like a “dissertation.” I needed to develop a Discipline that could carry me forward. In my experience, non-technical, “soft” skills, like Discipline, Integrity, Reliability, and Honesty have been important; Even if no one else appreciates them. I need to keep a personal Discipline. For example, I get up every day, quite early, even though I don’t need to, and walk a couple of miles, first thing. It helps me to clear my head, and plan out the day’s work. I also never work in sweats (except if I need to do a bit of work, right after my walk). I think that I need the structure imposed by dressing for work. I am now partnering with a couple of other folks, in a non-profit endeavor. It is working quite well, but we also have a very flexible plan. That’s mostly because of me. I insisted on a “pave the bare spots” approach[1]. Our project is morphing as we develop it, and I couldn’t be more thrilled. As an added bonus, it uses that backend that I developed a couple of years ago[0]. It has also allowed me to learn a great deal of stuff, and I love to learn. > we went through the user stories, completed those, created a story map, devised a roadmap, and clarified the scope of the MVP. I’ve become less-than-enamored of this approach. I know that makes me apostate, but I haven’t seen it bear fruit (besides a couple of withered crabapples), in my personal experience. What has worked for me, is “paving the bare spots.”[1]. I start with a vague, general project concept, then work on creating usable, high-quality partial prototypes, quite quickly, with built-in flex points. It has worked a charm. It is especially valuable in getting useful stakeholder involvement. It helps them to feel good about the project, incubates their sense of “ownership” (and commitment), and we create stuff that is actually useful to the end user, as opposed to “meeting specification.” Also, the very old practice of “constant beta” has paid dividends. This means no development or alpha release stages. The product is always in “beta-quality” stage, even if only partially done. The first release is “beta,” not “alpha.” I never say “I’ll fix that later.” If I encounter a bug while developing, I stop forward movement, until the bug is fixed. I may say “I’ll implement that later,” but I don’t leave known bugs behind me, and I’m constantly testing. Ultra-high Quality is important to me. I write highly-structured, heavily-documented code, with thorough (seldom automated, at first) testing, and am very hard on myself. A significant benefit of this approach, is that we have very solid product to show in that important “shopping around” phase of things, and that phase can start quite early. If we want a potential investor to look at the product, we simply loop them into the TestFlight group. No chaperone necessary, and no sacrifice to The Demo Gods. In fact, any feedback or bugs found are appreciated and integrated into the project (or we develop talking points to address the issue). An important part of this, is that the “prototype” code is actually ship code. It is the product, not a “sizzle reel,” so this means that actual project progress is demonstrated; not some vague, hand-wavy “this won’t take long to realize as ship code” promises. The jury is still out on where this is all going, but I’m extremely happy with the integrity of my work. [0] https://riftvalleysoftware.com/work/open-source-projects/#baobab https://riftvalleysoftware.com/work/open-source-projects/#ba... [1] https://littlegreenviper.com/miscellany/the-road-most-traveled-by/#paving https://littlegreenviper.com/miscellany/the-road-most-travel...
aryehof 6y ago
Thank you so much for sharing this. My first thoughts were that you dove into what you could control. Those aspects of the product related to non-functional requirements. However, it’s really the functional requirements that primarily count for a customer. It’s a feature of our times that nearly all programmer attention is paid to technologies and plumbing. What’s left, how to determine “what” should be produced and how to model that into code, without regard to plumbing, persistence, user-interface/s or interaction with other systems, seems long forgotten.
olieidel 6y ago
Thanks for sharing - it takes a lot to share these sort of personal experiences. I've definitely been there, too. Aside from all the good and valid comments about reducing scope and shipping an MVP, I'd like to raise another point which may be controversial (or even wrong), but still worth raising: Would it have been different if you had used Rails? A few of the problems you mention (rich text editing, validation, and to some extend, pdf exports) are very easily solved in Rails. Take rich text editing: It's literally a couple minutes to use ActionText. Or validations / forms, there's really not much work to do. PDF exports are also not too hard via wicked_pdf [1] if you're okay with fixing some formatting quirks later on. I've seen both worlds by writing tons of JS / React code myself, and at that time (2016-2018) those problems were almost an order of magnitude more time-costly to implement in SPAs. I remember react-router.. not great memories. Of course, all the points reducing MVP scope still hold, but.. if you could have had all those features (nearly) for free, would you be at another stage now? Who knows. [1] https://github.com/mileszs/wicked_pdf https://github.com/mileszs/wicked_pdf
chiefalchemist 6y ago
Extrapolating a bit. What seems to be missing from this story are any significant milestones. Humans need miletones. Perhaps more than projects do. Sure, you can psych yourself up every morning about how excited you are, about the greatness of the destination, and so on. But long timelines without significant feedback will catch up to you, your team, your investors, to everyone involved. When things stagger on and on and on, you lose focus, you lose confidence, and in that context bad decisions increase; as does friction between the team. Lean doesn't simply build products. Lean also addresses the human side.
- renke1 6y ago
  That's very true. What also helps is not only to have milestones but also have people (preferably prospective customers, but friends are great as well) you can show your milestone results; this often serves as some kind of reality check.
jiofih 6y ago
> the project needed to be (almost) re-created from scratch > the build system, Docker/docker-compose, continuous integration, authentication, internationalization, etc > created a wiki, migrated the code to a monorepo, created/cleaned up the backlog, etc. > created a story map, devised a roadmap, and clarified the scope of the MVP > replaced Angular Material by Tailwind, created our own theme, refactored the data model This is why. A year went by and no product work was done, none of this was necessary. The very first thing that should have been built is a MVP, that main screen that was only tackled 9 months in. Strongly recommend studying “The Lean Startup” and learning how to be stoic about tech. That’s how people deliver working products in three months.
- highfrequency 6y ago
  what does it mean to be stoic about tech?
  - jiofih 6y ago
    Not jumping on bandwagons and exercising restraint - you don’t need all that shiny stuff to get the job done.
superasn 6y ago
My only take-away from this article is also something I deeply believe in: Use boring technology(1) if you're doing it for business. (1) http://boringtechnology.club/ http://boringtechnology.club/
- raphaelj 6y ago
  I always find it amusing that PostgreSQL is classified as "boring tech". I'm using it every day, and I'm always amazed by how wonderful this piece of software is. PgSQL help me doing thinks in seconds that would take days do to in Mongo.
XCSme 6y ago
Anyone can explain why using a NoSQL database was a limitation? He says that they had to switch to a RDBMS for offline usage, but why couldn't a NoSQL dataset be saved locally for offline usage?
- dSebastien 6y ago
  We designed our documents just like separate tables and didn't want to denormalize the data model. This was a mistake and known anti-pattern for NoSQL, because we just can't easily join different documents together. It caused issues with updates (e.g., If I change the state of a meeting document that is linked to a number of other documents, then I need to fetch/update those separately) and all without a transaction, because CouchDB only ensures atomicity at the document level (& with bulk ops). It's far from intuitive, prone to error, and complex. Certainly, having a classic RDBMS with an powerful ORM makes such operation much easier in practice, and safer as well. I'm not bashing on NoSQL; we just use it badly and suffer from all the drawbacks while getting none of the benefits (since our schema is strict after all..). CouchDB was appealing for offline-first because it exposes a RESTful API & means to replicate entire databases. So we had in mind to use PouchDB on the client-side; store a copy of the data locally while online, saving changes locally and synchronizing when going back online. So it allows for a true offline-first approach, not a middle ground where you keep access to the subset of the data that you already got while browsing the app. But it doesn't mean that it's easy, or that it ain't possible to do the same with a classic RDBMS, or a mix of tech...
shujutech 6y ago
It's safer to use relational db for all business applications since transactions integrity is required most of the time. To reduce complexity, check out: https://github.com/shujutech/StORMi https://github.com/shujutech/StORMi http://shujutech.mywire.org/corporation?goto=ormj http://shujutech.mywire.org/corporation?goto=ormj
jsteinbach 6y ago
What I found curious is the equation money not gained = money lost To me that sounds like the perfect mentality for a burnout. I would think that you used your time (i.e. opportunity) not for monetary but personal gains (i.e. experience). Ideally you would have turned that experience into money again, but just because that didn't happen doesn't mean you didn't gain anything.
- dSebastien 6y ago
  It's not all black and white though. I did learn a lot (especially about myself in recent months), but this all came with a very real cost. If I did consultancy or went back working full time as an employee, I'd have a ton more money in the bank. It does impact my family. It is money lost, no matter how you decide to look at it :) I'm not saying that I regret doing what I did. What I regret (but am not going to cry all day about) is the bad decisions that I've made during that part of the journey.
  - tasuki 6y ago
    Time is money, no double counting: either you can say you lost the time, or you can say you lost the money. Claiming you lost both would not be true in this case.
cutenewt 6y ago
OP, thanks for sharing your article. On the balance, you aren't doing anything wrong. The only real takeaway is entrepreneurship is hard. VERY HARD. You will make plenty of mistakes. Technical mistakes. Business mistakes. Mistakes that cost years, maybe even decades. Mistakes that will cost you thousands (hopefully not millions). Don't obsess about "we should have done this" or "I should have done that." You'll beat yourself up unnecessarily. If you want to do entrepreneurship, keep at it. Find problems. And fix them fast. If you don't have the bankroll to do it (or just fall out of love), then you can quit too. That's ok.
- dSebastien 6y ago
  Thanks! Right, it is hard. But I like challenges; so I'll keep trying =) I don't like dwelling on the past too much, but I find it incredibly useful to look back every once in a while, and take a good hard look at what I accomplished. There are different ways to look at things. I've quit a well paying job, but managed to keep the same quality of life (even improved in some aspects, independently of Covid-madness), I launched a company, had new and interesting experiences, met cool new people, published a book, etc. We can tell as many stories as we like in life. Ain't that fun? :p
dSebastien 6y ago
I'd like to thank everyone who took time to comment and share thoughts/ideas. All of this feedback is super valuable to me, for many reasons. The first of which being the push in the back to change my approach drastically and obsess on the product much more than on the technical beauty. I'm not kidding, but this morning I went with an axe through the backlogs and have pushed back so many tasks that I was emotionally attached to. Now, the "MVP MUST" version is planned for the end of this month rather than March. A change of mentality really makes you see things very differently. Anyways, it was time for the madness to end.. right? ;-) Thanks again!
ak_111 6y ago
Given that one of your partners is a "Lean Coach" did you consider to first sell a no-code service. Perhaps one focused on helping/coaching/training companies manage remote meetings effectively. This service would be admittedly a tough sell, and hard to scale since it would depend on your partner attending many meetings and providing feedback for each one. But even if you get a few customers, then you have some cashflow and provide a sales channel to slowly start onboarding them on full-code product as you build more features. It will also allow you to quickly identify the most useful features to prioritise, and some features you might have not even thought about. Lastly, it would give you much more credibility when trying to raise seed funding if you are able to show you sold the no-code version of the service.
- dSebastien 6y ago
  Yes, one option currently on the table is to bootstrap ourselves using a service model at first; either around the core business (probably better I imagine), or through IT services. Another option would be to monetize the existing version that my partner created and is actually using with multiple clients already (made using FileMaker) Another is to try and avoid funding for one more year, using more of our personal savings to continue moving forward (albeit with a different approach). We still have to decide.. It's a pretty tough decision, and not straightforward at all :)
overallduka 6y ago
First, thank you for writing this, It's really cool to see others entrepreneurs sharing their experience, I believe this post here will help you a lot, I agree with many opinions here, the main thing would be the MVP opinion, you are focusing too much on secondary features(like PDF export) and could not finish the primary feature I guess (if yes you should launch it). I am a developer and entrepreneur, I have sold a SAAS product 3 years ago and will sold my other SAAS this year(much bigger), I built entirely my SAAS products. As almost everybody here said you are being too perfectionist, I would suggest you focus on the main feature, the feature that was mentioned when you had the interest of that first customers, make sure this features works well and launch it, then improve it. After you have your first 2 or 3 clients you will see your motivation go higher, all the team will be motivated, also, these customers will ask for critical things that you forgot, but when they suggest things you have to be critical and think if the feature will benefit multiple customers, not just the guy who asked, doing this in 3 months you gonna have a good product. I really would suggest you stop writing tests in this moment, takes time and probably in the future the code will change, which will require 2x work, but if you think you are fast doing this is okay. Another thing I would suggest is just comment features that are not finished and you think are not part of the primary feature, don't try to finish those things, just comment it out, if some customer asks for this in future you finish it. My approach is a bit radical, but I learned this way, customers will ask for stuff that matters at some point, if they think the primary feature is good enough, and for you to know if is good enough, you need to launch it, just make sure it works ;).
- 10x-dev 6y ago
  Dumb question: how does one sell a SaaS in practice? Hypothetical scenario: solo engineer develops bitcoin trading platform. Wants to sell it. Then what? What steps does the engineer/founder take to sell this?
  - overallduka 6y ago
    Sites like these: https://feinternational.com/ https://feinternational.com/, they guide you through the process, but you have to reach certain MRR(2k minimum I think), the price of the SAAS business is calculated using a multiple of the MRR(20x~48x).
rvba 6y ago
I think the guy has just low technical skills. He writes that he managed a team (that means other had to work), that he prefers team work (usually it means that someone else has to do the work). Then he started with the classic: previous code is bad so I rewrite it from scratch. Then came to a conclusion that his own code is bad and shouls be rewritten. And only then author had another conclusion: it was unlcear how the product should work. So they hired an UX person. Then we learned that moving buttons around requires back end changes (wtf?)... And then we learned that the author still didnt know how to make the main feature of the product. My guess: if they hired another programmer the other person would code it in few days. Author looks like a manager / team player - someone who never did anything on their own. Also I really loved the part about previous code being bad (classic) and rewriting everythig just to say that own code is bad too and didnt move the project at all. I wonder what part of the solution even works. Probably nothing apart from login window. Also the part where the author wrote that after coming back to previous work they had to do lots of frantic work... sounds like normal work. But author wasnt a manager anymore so the work had to be made: hence it was so painful. No more possibility to delegate the problem and do nothing all day. And real deadlines.

333 points by dSebastien 6y ago

> ” Between July and September, I worked on different things: the build system, Docker/docker-compose, continuous integration, authentication, internationalization, etc.” Authentication seems to be the only thing the author should be working on at all for a MVP. And even so, I would personally choose AWS Cognito or something like that. From reading this, it seems to me that the issue is a mix of harmful obsession code quality and bad priorization of what to work on. Probably some feature creep too, even with the author claiming they cut all to the basics.

javajosh 6y ago
Yes, its interesting from that list of things he did for 2 months one cannot discern what his project was!
- bombcar 6y ago
  Spending time reading horror stories on HN can lead to a form of paralysis. While it’s true bad decisions can be made at any level and anytime early on it is much more important to get something (anything) up and running - even if you scrap it later.
leesalminen 6y ago
Just finished a MVP idea I had and used Firebase for everything, including auth. Auth took a total of 15 minutes to work into my react SPA. Called it a day and moved on feeling very impressed with Firebase.
- nmfisher 6y ago
  I'll reiterate what I said the last time it came up on HN - this is exactly why I use Firebase, and why OP probably should have done the same. It's literally 15 minutes to configure/integrate, and you're done. You can then move on to building/iterating on actual features that matter to customers. Until you've proved you're building something that people want to buy, your data layer only needs to do the absolute bare minimum (store some data). It doesn't matter if it's not scaleable, performant, extensible, etc. 99.9% of the risk is that you fail because you're not building the right thing, not that you fail because Firebase wasn't appropriate. You have a limited number of hours in every day, and they are much better spent building features side-by-side with customers. You won't even know that Firebase is a bottleneck unless/until your platform is successful, and at that point you're in a good position to migrate/rewrite/whatever. A couple of commenters smugly pointed out that they were contracted to fix Firebase issues later down the track, and that's why they would stay away from Firebase in the first instance. First up, there's clear survivorship bias there - the fact is these businesses survived and were in a position to hire someone to upgrade their data layer. That's meaningful in and of itself. Second, don't pay too much attention to people who have never bootstrapped anything from the ground-up. What works in a mature, stable, well-funded organization is not what works in a solo, early-stage startup that's strapped for cash, time and equipment.
  - nicoburns 6y ago
    Setting up postgres on heroku is similarly quick and straightforward, also comes with a free plan for when you're just starting out, and won't leave you with the headaches you'll almost certainly have later with firebase. Firebase is slower to iterate on, because you have to bake your query patterns into the schema (yes your data still has a schema even if you don't have to define it up front) Using firebase for auth and/object storage makes sense. But I don't understand why anybody would choose to use the database(s) except for a few niches where realtime is critically important and query flexibility / data integrity aren't.
    - nmfisher 6y ago
      1) Firebase storage has the advantage of one-click integration with auth (Google Auth, Sign in with Apple, etc). Probably not difficult to achieve with Postgres on Heroku, but why waste a couple of hours on something when I don't need to? 2) My golden rule is to avoid anything that doesn't get you closer to a customer in the next 14-28 days. For some use cases, Postgres on Heroku might help you do that. For me (see next point), it's just adding another platform/service for no reason. That will only slow me down. 3) I disagree that "Firebase is slower to iterate because the schema is implicit" (at least, as a hard-and-fast rule). It depends on how complex the schema is. You iterate on implicit schemas by rewriting code, and you iterate on explicit schemas by rewriting code and the schema itself. This is faster for complex data models with strong integrity requirements, but for basic data models (think mobile game leaderboards, etc) it's just unnecessary. That's not to say that any of this is a huge amount of extra work. I'm sure a lot of people are reading this and thinking "Postgres will just take an afternoon to hook up, why not?". The reason is that spending that afternoon with a user is infinitely more valuable than spending it hooking up Postgres. You have to be ruthlessly focused on what moves you forward, which at an early stage is simple - features, customers, users. On any given day, there are literally hundreds of things you could do that "will just take an afternoon". If you allow them to distract you, you'll probably end up like OP - 2 years in with a well-architected system that doesn't have any customers.
      - nicoburns 6y ago

echelon 6y ago

Medium hellscape. They now require an account to read.

hydroxideOH- 6y ago
Open a private window and read it in there.
- echelon 6y ago
  My criticism is that we've gone from an open Internet to one where every silo wants us to log in. I hate this system. Medium doesn't write any of these articles and they think their value add or marketplace or whatever it is that they've built is in exchanging content for personal information. I'm sick of post-2006 Internet and I want things to go back as they were.

JamesBarney 6y ago

Before I riff on him a little, I'm very thankful the author shared his experience, that takes a lot of bravery. He's also not the only person to make this mistake, so many have. I learned a lot of these lessons from making a bunch of expensive bone headed decisions myself. I also am not implying that just because he fundamentally doesn't understand an MVP or how to build a lean startup that he isn't an awesome dev, I honestly bet he is a great dev who just learned a valuable lesson(3 times :| ) about what an MVP truly means. ( I haven't shared them because I'm awful writer, but I hope to one day ) But wow does this guy not understand an MVP or what matters for a startup. > I became more and more “aggressive” about reducing the scope and focusing on the essentials You should do this day one before you write a line of code. There should be nothing you can cut from your MVP. For the first two months of my last MVP to edit data you sent an e-mail to a dev who wrote a sql script that edited it for you. We still added 3k MRR each month. For every feature you should ask "What would happen if I cut this out?" if the answer is anything but "It literally wouldn't work for any individual who could conceivably use this product (with a broad definition of conceivable) then the answer is cut it. Is it a differentiator? cut it. Does your product suck without it? cut it. You can always trade time for features, but you can never trade features for time. > Maybe I obsess too much about code quality The answer is YES YOU DO! Code quality doesn't matter. It really doesn't matter. What killed your first three startups? Was it code quality? Or was it was not getting out a product fast enough, not iterating quickly enough, and not finding product market fit fast enough. This experience is typical. If the code quality on your MVP doesn't physically disgust you, you're probably focusing on code quality too much.

BobbyJo 6y ago
It's funny how different peoples' experiences can be. I personally witnessed one of the two startups I worked for fail as a result of code quality. Things ended up being too slow and error prone for some of our customers, and eventually they left us behind. We tried to attract new customers, we had amazing feature set after all, but the performance/stability hole ended up being too big to dig ourselves out of before we ran out of money. I agree that the poster likely focused too much on it, but it's definitely not something you can ignore completely with the assumption you'll always have extra time later to go back and fix things.

vessenes 6y ago

This is a hard read for me, because I can sense the vision and determination behind the last two years, but there has been some really poor decision making as well. Here are some things that come to mind reading this: * Most people are not cut out for startups, and I would include some of the people you've recruited along the way, by your description. It's hard enough to get a startup off the ground without having semi-motivated partners. I think you do need a partner or two, but I wouldn't say you have been brutally honest about what exactly you need to be successful yet. * This is partly a Europe / West coast US thing, but one thing Silicon Valley does well is create a solid revolving door for entrepreneur types -- in general, if you want to go try a startup, go for it -- even if you fail, ideally, you will learn some new skills not on the big company's dime, and come back more seasoned and ready for another round with the big co. I know this is harder to pull off culturally in Europe, but I think some of the paths toward successfully pulling this off involve selling your experience harder, (along with getting broader experience). If you're depressed with a year of failure, you will feel like you're slinking back. By comparison, I would hold out examples of one of the moviepass founders who bemusedly reports in interviews he's in demand for a follow-on startup, despite launching a massive massive crash and burn startup. And it's right that he's in demand; he got a startup launched with huge scale, brilliant free press and marketing, and briefly shook up an industry. I bet he'll be back. Which leads me to point three. * You have picked terrible, terrible markets. Tiny markets. Markets which require public tenders. In tiny countries. Markets where purchase decisions are made nearly infinitely far from those who require the benefits of the purchases. Seriously, these were terrible decisions. You compounded them by not getting some initial sales done first. I imagine that as you read this, right now you have roughly ten reasons why your path made sense at the time. And, I bet it did make sense at the time. But it was the wrong path. If you want US west coast philosophy, I can say that some of the best incubators on the west coast consider maybe their number one core skill market testing -- they work very, very hard at testing out if a product will sell before they write a single line of code for it. To the point that places like Pioneer Square labs are actually turning their product-fit test facilities into SAAS model products in their own right. If you prefer value investing, Buffet's aphorism is helpful here: it's better to be mediocre at a great business than it is to be great at a mediocre business. You could be a brilliant, brilliant coder and a brilliant, brilliant product person, but it just won't matter if you are selling something nobody wants to people with no money. At any rate, my personal advice to you is to listen to your urge to be an entrepreneur, and set your sights both much higher and also much more narrow. Pick a giant market that you care about, pick a niche you can do some damage in, get some test sales in the door, and I think you'll find you feel a lot more successful, and it will paradoxically be less emotional work. If you can get a little success that can help aim your company as you iterate. Also, it's hard work to write your retrospective, thanks for doing it -- I hope you find some success, and can update so your readers get a feel for what to do on their own paths. In summary, product-market fit is the only thing, and you should get it before you do anything else. If you sell crack cocaine, the world will beat a path to your door. Crack cocaine I've seen this year come across my VC fund's desk: * paramutual insurance (merchants want it, customers want it, it's cheap to provide). * product authentication which works from factory to distribution to retail to end customer (manufacturers really really want and need this and can convince customers it's in their best interests) * defi lending (people want to borrow on their crypto, and want 0 friction to do so) * Instant vendor network credit scoring as the real value add for supply chain management - large cos want insight into their vendor world and early warning of problems, small vendors desperately want cheap financing * high margin trading volatility of all sorts - people love to gamble * home insurance bought by app -- nobody wants an insurance agent, or spammy calls. Most of these could have their own niche spins, but the point I hope to make is that there is a wide world out there of problems, each of the above are giant markets, with plenty of room to be 'mediocre' and still have happy customers, and generate huge wealth. Best of luck in 2021!

jokethrowaway 6y ago

That was an amazing read! Thanks for sharing your experience. The obvious feedback is to let go of perfectionism and ship a real mvp. If you're spending 2 years on it, it's not a mvp. Before jumping on a new idea, I'd suggest to think how you're going to sell it and test the market by talking to people in it. Getting better at finding cofounders (as in, cofounders who would think about these problems while you build the product) would be good as well. Personally, I gave up on that last one and I'll just fly solo and smaller, but you may be more optimistic. Also I'd recommend you to pick something smaller and easier to sell. A generic B2B SaaS API to solve a small problem can help you build a passive revenue stream and free you from worrying about money and plan bigger, better, more interesting projects. Funnily enough, during uni I made an app which was making a decent amount of money in advertising (netting everyday a daily rate of a mid developer contractor rate in London) but didn't have a future. I decided to start a company doing something bigger and better and failed miserably. Some contracting, some more working and a few kids later, I'm back at square one building more small passive revenue streams. Look up Pieter Levels's presentation Bootstrapping Side Projects into Profitable Startups.

10x-dev 6y ago

Great read. Thanks for sharing! I too think your definition of MVP needs to be adjusted. It sounds to me like an excited user came up with the MVP feature list, not an experienced developer, like "it's gotta have rich text editing capability and pdf export and offline support and nice ui!" because how can you not highlight important notes in bold and download your notes later, right? And it's got to be pretty to look at, and obviously needs to work offline when the wi-fi is down, right? No, wrong. Everybody I know gets dreamy at first. It's your job to bring people down to earth. Simple text editing at best, and I do mean 'at best'. Basic UI, online only, unsexy solution. If you can't sell that, then you are either not solving the right problem, or it's just not that big of a problem to begin with. Kubernetes, and Docker and CI? Cool tech, I suppose, but time wasters. Your release process should be scp-ing and extracting a zip file on the prod machine, or git checkout the files. The one thing that went right was sticking with Couchbase imo. The world is filled with people who regret rewriting the persistence layer for an MVP under pressure. I am one of them. Several times over. Do not doubt the decision. It was the right choice. Finally, schools and restaurants don't have money for software. I know folks who wrote school software. It was a travesty - the government gets involved at a certain point and wastes your time, the school budgets are razor thin and will not throw money at you. Restaurants are usually low tech as well. Most pay only for basic websites. Find markets with deeper pockets.

sfeng 6y ago
For the record, I've used CouchDB multiple times and it was a mistake every one of them. Moving to Postgres never takes as much time as you'd think, and having a database which is rock solid, understood, and performant is a great idea. Choose a DB which you will be happy with when there's an issue at 4AM, not the one fun to use at 4PM.
- j45 6y ago
  There is no small amount of time wasted taking data from non relational dbs and making it relational. If you prefer nosql, consider something like Hasura which reveals a graph on top of a Postgres dB. I’m not affiliated with either but it’s important to not make tech decisions based on what a developer hears others like to use.

wiradikusuma 6y ago

It hits home with me, and the TL;DR is: Don't bother setting up "proper" DevOps (but you still need it, just to get going), Don't bother building for scale, Don't bother proper code lifecycle... Until you have some traction. Focus on your MVP. Your truly scrappy MVP. Applicable most (only?) when there's only 1-2 tech guy. More than that, you need some structure (communication issues). Technical debt? Yes. Server will crash with angry customers? Definitely. Will never experience those problems because you product will fail anyway? Most likely. Also, refrain yourself from using that latest JS framework. Use what you know like the back of your hand.

redis_mlc 6y ago
Just to expand on this: > Don't bother setting up "proper" DevOps (but you still need it, just to get going) Correct, you can use a Makefile or make.sh for years, more to remind you of the build process rather than something that needs to be continuously run, in a startup. Time waiting for a build process is time not adding user features. > Don't bother building for scale Correct, since finding the true requirements for scale requires having many users, and the unicorns that you admire had multiple rounds of scale-out rewrites. (You can add Google Analytics to your pages to see their usage. I've seen some companies do this as a lightweight interim APM before. Pages that nobody uses aren't a bottleneck.) My current SaaS app has a built-in APM using pre-auth, post-auth and post-load hooks that I added after version 2.0. I learned the auth was slow, but the page generation was fine, so I fixed the auth routine. > Don't bother proper code lifecycle Correct, since you don't know what the final version will even look like. The exception is if you've done similar projects with a similar expected load, then you can skip a lot of the steps that didn't work before. My goal is to write code to Open Source standards, but I realize that rework will be needed later for scale, etc.

irjustin 6y ago

Thank so much for writing this. The detail, the hurt, pain, everything. It's super real and the experience is not for the feint of heart. Please stop coding. Go find a paying customer. Whatever it takes. Lots of the other comments echo this sentiment, and you already know this in your bones. The problem us engineers face is we tend to hate sales. Whether we're bad at it, hate the experience, or insert X reason... we avoid it like the plague. At least I do. And so we support the organization by being the best damn engineer we can. Features features features. But there are times when that isn't the answer. This is one of those. It's Monday, the day you work on the SaaS - pick up the phone and make calls. You're not an engineer - you're a founder.

ku-man 6y ago
Unlike the US, in Belgium software developers don't call themselves engineers... unless they are actual engineers. So, careful with the titles.

issa 6y ago

I think the main lesson here is that an MVP has to be small enough to be completed in a reasonable time. Even if it means boiling the product down to one single thing. Everything else can wait.

dSebastien 6y ago
Clearly! Haha ;-)

trestenhortz 6y ago

That’s a great story and I can really feel his pain.

deleted 6y ago

[deleted]

jy2947 6y ago

Thanks for sharing! I also wonder whether the OP should have made clear decision (and expectation) between bootstraping vs startup, because I think they require different mentality, operation style and even market. With startup he and his cofounders could focus on applying incubator and/or angel investors early on. They would get some feedback on their ideas. They could even get a little funding to hire a designer or contractor to help build the UI (which appears to be the big drag). In this case you are trading ownership to additional support systems. If you do bootstrapping, then you'd need to prepare for the longer timeframe, and financial burden. Maybe still keep the original full-time job and working par-time on the side project.

ricc 6y ago

I personally have a very simple takeaway: Never half-ass two (or more) things. Always whole-ass one thing. I think the OP was not prepared to completely dive in to his startup project which led to distractions, i.e. side business and writing, thus compromising dev time, mental recovery time, and eventually morale.

adrianmsmith 6y ago
Bill Gates and Warren Buffet famously stated the key to their successes had been “focus”, i.e. going all-in on one thing.

tmikaeld 6y ago

"I became more and more “aggressive” about reducing the scope and focusing on the essentials; still, I didn’t want to forget about code quality." After reading all of it, it seems to me that the problem is right there. Security, maintainability, offline-first, horizontal scaling etc. Should have just thrown these out the door and put every client on their own VM, with local database and automate backups and updates. You'd get something out the door and could make sales, then re-factor for the next iteration of the app. You'd be hard-pressed to find any client that wouldn't be sufficiently sustained on their dedicated hardware (or VM).

grumple 6y ago
VM for a mobile app?
- tmikaeld 6y ago
  Absolutely, highly scalable VMs are available for less than 2€/mo from providers like Hetzner and OVH (less at scale), with an included "global" redundant network. Does it make sense if your business idea is having thousands of customers on a single VM by using containers? No, of course not! But it does make sense if each customer is worth more than 2€ per month.
  - XCSme 6y ago
    I think this is what's wrong with today's SaaS and web environment. People thing that by going with AWS, creating a complicated auto-scaling infrastructure that supports billions of user is the way to go and the most cost-effective way, but while doing so many forget that using the simpler solution that costs a bit more can actually save time and money. What's the point of trying to save $1/month per user if you have no users yet and achieving this cost reduction takes one or two more years of development time.
    - jokethrowaway 6y ago
      AWS is rarely cheaper than competitors. It just offers more for more.

kureikain 6y ago

Reading this I realized the same mistake that I made. It's because we focus on a product that 1. need lot of front-end works 2. target a user-base that need a lot of onboarding I have a side project that I worked on in 10 years and still doing nothing...Its scope is too big and because It requires some kind of front-end works, which isn't my strong suite, it becomes a constant battle to say what should I do, how should I make UI/UX intuitive. Then after I sitting down after 10 years(and still have nothing to show), I leanrn about 1) and 2). Then I think in order for me to move forward when I have a day job, I have to focus on something that require zero or very little front-end works and can easily self onboarding. I did that idea. And something I think I can finished in 2 weeks ended up taking me 3 months and still not 100% polished but at least I have finally launch it and have my first paid customers So my advice to anyone is to find something that requires minimal front-end works can can easily on-board new users. --- the service is https://hanami.run https://hanami.run an email forwarding service if you are curious

lonbigtech 6y ago

How much of that 2000 hour was spent on the core experience, the meetings screen? How much of the work that wasn’t spent on the meetings screen had to be reworked due to changes with the meeting screen? How many times has the meetings screen been shown to prospective customers?

dSebastien 6y ago
On my end, probably 50%. I've logged ~200 hours on that screen and the surrounding components. But I get your point; that should've been almost the only focus. I did was time with tech, build, code quality, release automation, ci, code formatting, git workflows, project organization, lazy loading, and whatnot. It all adds up and eats time that I didn't realize I didn't have to spend in the first place.

baby 6y ago

If I may, it seems like you’re doing too many things at once, and yes the context switch is a killer.

ruvis 6y ago

> but the people we discussed with weren’t interested at the time; they were scared of traceability and preferred to be able to avoid taxes (no kidding :p). I'm a project manager in construction, and I still have to make my quotes in excel or word because of this. Don't know if this is a typical belgian thing, but it's pretty ridiculous.

trestenhortz 6y ago

When building an MVP stop flouncing around with your professional software development. Build the damn thing and get it launched. Every singe dollar you waste on CICD Docker and testing sends you closer to the clock running out and failure.

dSebastien 6y ago
Indeed. But as a newbie, you first need to start feeling that the clock is really ticking. And fast. I think that during the first year, I just had no pressure at all. I worked very seriously, but didn't feel external pressure. I had just put enough money aside, I was glad to finally work on my own terms, etc. And thus I thought it was all okay, and that our pace was normal, given the time constraints that we had. Now I see clearly how much of a fool I was.. ;-)

didip 6y ago

Heh, I totally did the restaurant platform and just like him it failed because all of the customers run razor margin business and some of them are still uncomfortable with the internet. But unlike him, I noticed the downward trends and decided to cut the losses even though I had managed to hit the break even line. I thought it was a pretty good decision on my part.

fruty 6y ago

Hi, long time tech startup CTO and CTO freelancer here. First of all, thanks for sharing your story. I think the real lessons here is that: - a founder CTO needs to be very strong on product: I never accept offline capabilities or even mobile compatibility for a MVP, this is simply never necessary to get the needed early feedback - as a tech startup cofounder, your infra should be a docker-compose.yml and that's it, your CI should be a README "ssh, git pull, docker-compose stop, build, up" and it should take max 3-4 hours to set up - caring about unit tests and the like is useless when you're still iterating fast, automated tests are good once the product is stabilized and you want to kinda "freeze" it or at least stabilize it and introduce some friction in the dev process to prevent regressions (you trade speed for quality) Sounds to me you spent entire months working on things which did not provide any business value

dSebastien 6y ago
You're right, thanks for the advice!
corytheboyd 6y ago
Agree on all points made here, though I haven’t yet been in the founding position myself.. yet :) Relevant side note: Docker compose is SUCH a nice tool for this type of work. It is very worth learning, but learning it takes time. Be careful not to confuse “we need to move fast” with “there is no time to learn how to properly use tools”. It’s worth understanding. You will have both initial nimbleness and something that isn’t far off from production ready. To be completely honest, I am still in the active learning phase with both Docker and Compose, but it’s helped keep me organized already.
OJFord 6y ago
'CTO freelancer'? How does that work?
- radihuq 6y ago
  Fractional CTO I think

edrobap 6y ago

> Early in 2018, after having worked for 10+ years as an employee, office politics got to me and I was tired of wasting time in meetings. I really wanted to quit, be my own boss, and have more impact on the world around me. In a lot of failure stories, I have seen similar starts. Entrepreneurs wanting to be their own bosses and hoping that they will stumble on to a problem that will change the world. If you don't have a problem already, it's a brute force approach that takes a lot of resources including your health. I believe one should always start with a problem. Secondly, being "my own boss" is really impossible if you are working on real and hard problems that succeed. Oftentimes, your customer is your boss. To solve for motivation, you need to give sufficient autonomy and ownership to your team.

ReDeiPirati 6y ago

> I feel almost ashamed when I think about how little we have to show for it. Maybe it’s normal, maybe it isn’t. I had the same feeling, and a very similar story, when I failed for the first time. The main problem here is the process (outcome of a 10yo developer mindset in an established company): too much focus on things that don't matter at that stage. Launching a MVP, and more in general starting a startup, is all about risk mitigation and more importantly simplicity. I saw too much commitment in building and not enough on validating (especially for value that is the first big risk to mitigate).

blunte 6y ago

This doesn't help TFA, but building a successful business is usually really difficult (based on what has been seen and written about other successful businesses). Also, many entrepreneurs fail multiple times before succeeding at a business. Indeed, sometimes luck is against you. COVID was probably not on most people's risk models, so who would know it was a bad time to start most businesses? And while sunk cost fallacy is a real problem, I suspect that some terminations with that excuse might have been successes if pursued further. But having a family and children is a significant priority conflict with being an entrepreneur, so I certainly don't judge the TFA. But likewise I don't think I would use the sunk cost expression.

valentinu 6y ago
I second your opinion about having a family to support will conflict with being an entrepreneur. It reminds me about the reason #9 not to start a company: http://www.paulgraham.com/notnot.html http://www.paulgraham.com/notnot.html > I wouldn't advise anyone with a family to start a startup. I'm not saying it's a bad idea, just that I don't want to take responsibility for advising it. I'm willing to take responsibility for telling 22 year olds to start startups. So what if they fail? They'll learn a lot, and that job at Microsoft will still be waiting for them if they need it. But I'm not prepared to cross moms. > What you can do, if you have a family and want to start a startup, is start a consulting business you can then gradually turn into a product business. Empirically the chances of pulling that off seem very small. You're never going to produce Google this way. But at least you'll never be without an income. > Another way to decrease the risk is to join an existing startup instead of starting your own. Being one of the first employees of a startup is a lot like being a founder, in both the good ways and the bad. You'll be roughly 1/n^2 founder, where n is your employee number. > As with the question of cofounders, the real lesson here is to start startups when you're young.

WJW 6y ago

While I enjoyed the read, I was perplexed by the author writing a long post about how busy and stressed he is and then casually mentioning that he also started a new book and inviting us to sign up for his newsletter right at the end. Stop letting all your plan Bs distract from your plan A mate.

dSebastien 6y ago
It's just the usual end of post that I use. I've been blogging for quite some time already; more as a relaxing activity than anything; I do like sharing what I learn about. I do try to monetize what I write, but it won't make me rich anyways ^^. The book doesn't distract me from the startup project; it's just another project, to which I dedicate two evenings a week and a few hours during the week-end. It's important to me for other reasons; mostly the will to share what I do know about, and the need to think about something else. I couldn't work on the startup project also during those evenings/week-ends. I don't want to be in burnout state just because I was able to pour in more hours each week. Question of equilibrium. Maybe I would've done that ten years ago, but not today.
- dSebastien 6y ago
  Regarding the stress, I manage to isolate things in my life well enough to keep going; otherwise I'd already be crawling in my bed crying ;-) I'm still employed, have no worries about my capacity to find a new job should everything else fail, and my family hasn't been hurt too badly by Covid so far. So I can't complain. I'm stressed about the project and where I'm going, but not about life in general. I still have tons of energy, motivation, will, and projects :)

ChrisMarshallNY 6y ago

Thanks for an honest, forthright chronicle. I wish you luck, going forward. For myself, after leaving the corporation that I had been at for 27 years, I rapidly discovered that no one wants to work with older folks; regardless of our skill level, so I went on an odyssey of self-actualization that played out a lot like what the OP described. I hadn’t sunk as much cost, and was realistic that I’d need to try out a lot of stuff before hitting my stride. I think that helps with the morale/motivation stuff. I also consulted a couple of cranky old men, with cynical views, and quite a few scars. It was humbling, but their clear-eyed judgment of my [scant] chances helped me to make some massive course changes, early on. I spent about seven months, a couple of years ago, developing a powerful, high-quality backend server that was never really meant to be used[0]. It was more like a “dissertation.” I needed to develop a Discipline that could carry me forward. In my experience, non-technical, “soft” skills, like Discipline, Integrity, Reliability, and Honesty have been important; Even if no one else appreciates them. I need to keep a personal Discipline. For example, I get up every day, quite early, even though I don’t need to, and walk a couple of miles, first thing. It helps me to clear my head, and plan out the day’s work. I also never work in sweats (except if I need to do a bit of work, right after my walk). I think that I need the structure imposed by dressing for work. I am now partnering with a couple of other folks, in a non-profit endeavor. It is working quite well, but we also have a very flexible plan. That’s mostly because of me. I insisted on a “pave the bare spots” approach[1]. Our project is morphing as we develop it, and I couldn’t be more thrilled. As an added bonus, it uses that backend that I developed a couple of years ago[0]. It has also allowed me to learn a great deal of stuff, and I love to learn. > we went through the user stories, completed those, created a story map, devised a roadmap, and clarified the scope of the MVP. I’ve become less-than-enamored of this approach. I know that makes me apostate, but I haven’t seen it bear fruit (besides a couple of withered crabapples), in my personal experience. What has worked for me, is “paving the bare spots.”[1]. I start with a vague, general project concept, then work on creating usable, high-quality partial prototypes, quite quickly, with built-in flex points. It has worked a charm. It is especially valuable in getting useful stakeholder involvement. It helps them to feel good about the project, incubates their sense of “ownership” (and commitment), and we create stuff that is actually useful to the end user, as opposed to “meeting specification.” Also, the very old practice of “constant beta” has paid dividends. This means no development or alpha release stages. The product is always in “beta-quality” stage, even if only partially done. The first release is “beta,” not “alpha.” I never say “I’ll fix that later.” If I encounter a bug while developing, I stop forward movement, until the bug is fixed. I may say “I’ll implement that later,” but I don’t leave known bugs behind me, and I’m constantly testing. Ultra-high Quality is important to me. I write highly-structured, heavily-documented code, with thorough (seldom automated, at first) testing, and am very hard on myself. A significant benefit of this approach, is that we have very solid product to show in that important “shopping around” phase of things, and that phase can start quite early. If we want a potential investor to look at the product, we simply loop them into the TestFlight group. No chaperone necessary, and no sacrifice to The Demo Gods. In fact, any feedback or bugs found are appreciated and integrated into the project (or we develop talking points to address the issue). An important part of this, is that the “prototype” code is actually ship code. It is the product, not a “sizzle reel,” so this means that actual project progress is demonstrated; not some vague, hand-wavy “this won’t take long to realize as ship code” promises. The jury is still out on where this is all going, but I’m extremely happy with the integrity of my work. [0] https://riftvalleysoftware.com/work/open-source-projects/#baobab https://riftvalleysoftware.com/work/open-source-projects/#ba... [1] https://littlegreenviper.com/miscellany/the-road-most-traveled-by/#paving https://littlegreenviper.com/miscellany/the-road-most-travel...

aryehof 6y ago

Thank you so much for sharing this. My first thoughts were that you dove into what you could control. Those aspects of the product related to non-functional requirements. However, it’s really the functional requirements that primarily count for a customer. It’s a feature of our times that nearly all programmer attention is paid to technologies and plumbing. What’s left, how to determine “what” should be produced and how to model that into code, without regard to plumbing, persistence, user-interface/s or interaction with other systems, seems long forgotten.

olieidel 6y ago

Thanks for sharing - it takes a lot to share these sort of personal experiences. I've definitely been there, too. Aside from all the good and valid comments about reducing scope and shipping an MVP, I'd like to raise another point which may be controversial (or even wrong), but still worth raising: Would it have been different if you had used Rails? A few of the problems you mention (rich text editing, validation, and to some extend, pdf exports) are very easily solved in Rails. Take rich text editing: It's literally a couple minutes to use ActionText. Or validations / forms, there's really not much work to do. PDF exports are also not too hard via wicked_pdf [1] if you're okay with fixing some formatting quirks later on. I've seen both worlds by writing tons of JS / React code myself, and at that time (2016-2018) those problems were almost an order of magnitude more time-costly to implement in SPAs. I remember react-router.. not great memories. Of course, all the points reducing MVP scope still hold, but.. if you could have had all those features (nearly) for free, would you be at another stage now? Who knows. [1] https://github.com/mileszs/wicked_pdf https://github.com/mileszs/wicked_pdf

chiefalchemist 6y ago

Extrapolating a bit. What seems to be missing from this story are any significant milestones. Humans need miletones. Perhaps more than projects do. Sure, you can psych yourself up every morning about how excited you are, about the greatness of the destination, and so on. But long timelines without significant feedback will catch up to you, your team, your investors, to everyone involved. When things stagger on and on and on, you lose focus, you lose confidence, and in that context bad decisions increase; as does friction between the team. Lean doesn't simply build products. Lean also addresses the human side.

renke1 6y ago
That's very true. What also helps is not only to have milestones but also have people (preferably prospective customers, but friends are great as well) you can show your milestone results; this often serves as some kind of reality check.

jiofih 6y ago

> the project needed to be (almost) re-created from scratch > the build system, Docker/docker-compose, continuous integration, authentication, internationalization, etc > created a wiki, migrated the code to a monorepo, created/cleaned up the backlog, etc. > created a story map, devised a roadmap, and clarified the scope of the MVP > replaced Angular Material by Tailwind, created our own theme, refactored the data model This is why. A year went by and no product work was done, none of this was necessary. The very first thing that should have been built is a MVP, that main screen that was only tackled 9 months in. Strongly recommend studying “The Lean Startup” and learning how to be stoic about tech. That’s how people deliver working products in three months.

highfrequency 6y ago
what does it mean to be stoic about tech?
- jiofih 6y ago
  Not jumping on bandwagons and exercising restraint - you don’t need all that shiny stuff to get the job done.

superasn 6y ago

My only take-away from this article is also something I deeply believe in: Use boring technology(1) if you're doing it for business. (1) http://boringtechnology.club/ http://boringtechnology.club/

raphaelj 6y ago
I always find it amusing that PostgreSQL is classified as "boring tech". I'm using it every day, and I'm always amazed by how wonderful this piece of software is. PgSQL help me doing thinks in seconds that would take days do to in Mongo.

XCSme 6y ago

Anyone can explain why using a NoSQL database was a limitation? He says that they had to switch to a RDBMS for offline usage, but why couldn't a NoSQL dataset be saved locally for offline usage?

dSebastien 6y ago
We designed our documents just like separate tables and didn't want to denormalize the data model. This was a mistake and known anti-pattern for NoSQL, because we just can't easily join different documents together. It caused issues with updates (e.g., If I change the state of a meeting document that is linked to a number of other documents, then I need to fetch/update those separately) and all without a transaction, because CouchDB only ensures atomicity at the document level (& with bulk ops). It's far from intuitive, prone to error, and complex. Certainly, having a classic RDBMS with an powerful ORM makes such operation much easier in practice, and safer as well. I'm not bashing on NoSQL; we just use it badly and suffer from all the drawbacks while getting none of the benefits (since our schema is strict after all..). CouchDB was appealing for offline-first because it exposes a RESTful API & means to replicate entire databases. So we had in mind to use PouchDB on the client-side; store a copy of the data locally while online, saving changes locally and synchronizing when going back online. So it allows for a true offline-first approach, not a middle ground where you keep access to the subset of the data that you already got while browsing the app. But it doesn't mean that it's easy, or that it ain't possible to do the same with a classic RDBMS, or a mix of tech...

shujutech 6y ago

It's safer to use relational db for all business applications since transactions integrity is required most of the time. To reduce complexity, check out: https://github.com/shujutech/StORMi https://github.com/shujutech/StORMi http://shujutech.mywire.org/corporation?goto=ormj http://shujutech.mywire.org/corporation?goto=ormj

jsteinbach 6y ago

What I found curious is the equation money not gained = money lost To me that sounds like the perfect mentality for a burnout. I would think that you used your time (i.e. opportunity) not for monetary but personal gains (i.e. experience). Ideally you would have turned that experience into money again, but just because that didn't happen doesn't mean you didn't gain anything.

dSebastien 6y ago
It's not all black and white though. I did learn a lot (especially about myself in recent months), but this all came with a very real cost. If I did consultancy or went back working full time as an employee, I'd have a ton more money in the bank. It does impact my family. It is money lost, no matter how you decide to look at it :) I'm not saying that I regret doing what I did. What I regret (but am not going to cry all day about) is the bad decisions that I've made during that part of the journey.
- tasuki 6y ago
  Time is money, no double counting: either you can say you lost the time, or you can say you lost the money. Claiming you lost both would not be true in this case.

cutenewt 6y ago

OP, thanks for sharing your article. On the balance, you aren't doing anything wrong. The only real takeaway is entrepreneurship is hard. VERY HARD. You will make plenty of mistakes. Technical mistakes. Business mistakes. Mistakes that cost years, maybe even decades. Mistakes that will cost you thousands (hopefully not millions). Don't obsess about "we should have done this" or "I should have done that." You'll beat yourself up unnecessarily. If you want to do entrepreneurship, keep at it. Find problems. And fix them fast. If you don't have the bankroll to do it (or just fall out of love), then you can quit too. That's ok.

dSebastien 6y ago
Thanks! Right, it is hard. But I like challenges; so I'll keep trying =) I don't like dwelling on the past too much, but I find it incredibly useful to look back every once in a while, and take a good hard look at what I accomplished. There are different ways to look at things. I've quit a well paying job, but managed to keep the same quality of life (even improved in some aspects, independently of Covid-madness), I launched a company, had new and interesting experiences, met cool new people, published a book, etc. We can tell as many stories as we like in life. Ain't that fun? :p

dSebastien 6y ago

I'd like to thank everyone who took time to comment and share thoughts/ideas. All of this feedback is super valuable to me, for many reasons. The first of which being the push in the back to change my approach drastically and obsess on the product much more than on the technical beauty. I'm not kidding, but this morning I went with an axe through the backlogs and have pushed back so many tasks that I was emotionally attached to. Now, the "MVP MUST" version is planned for the end of this month rather than March. A change of mentality really makes you see things very differently. Anyways, it was time for the madness to end.. right? ;-) Thanks again!

ak_111 6y ago

Given that one of your partners is a "Lean Coach" did you consider to first sell a no-code service. Perhaps one focused on helping/coaching/training companies manage remote meetings effectively. This service would be admittedly a tough sell, and hard to scale since it would depend on your partner attending many meetings and providing feedback for each one. But even if you get a few customers, then you have some cashflow and provide a sales channel to slowly start onboarding them on full-code product as you build more features. It will also allow you to quickly identify the most useful features to prioritise, and some features you might have not even thought about. Lastly, it would give you much more credibility when trying to raise seed funding if you are able to show you sold the no-code version of the service.

dSebastien 6y ago
Yes, one option currently on the table is to bootstrap ourselves using a service model at first; either around the core business (probably better I imagine), or through IT services. Another option would be to monetize the existing version that my partner created and is actually using with multiple clients already (made using FileMaker) Another is to try and avoid funding for one more year, using more of our personal savings to continue moving forward (albeit with a different approach). We still have to decide.. It's a pretty tough decision, and not straightforward at all :)

overallduka 6y ago

First, thank you for writing this, It's really cool to see others entrepreneurs sharing their experience, I believe this post here will help you a lot, I agree with many opinions here, the main thing would be the MVP opinion, you are focusing too much on secondary features(like PDF export) and could not finish the primary feature I guess (if yes you should launch it). I am a developer and entrepreneur, I have sold a SAAS product 3 years ago and will sold my other SAAS this year(much bigger), I built entirely my SAAS products. As almost everybody here said you are being too perfectionist, I would suggest you focus on the main feature, the feature that was mentioned when you had the interest of that first customers, make sure this features works well and launch it, then improve it. After you have your first 2 or 3 clients you will see your motivation go higher, all the team will be motivated, also, these customers will ask for critical things that you forgot, but when they suggest things you have to be critical and think if the feature will benefit multiple customers, not just the guy who asked, doing this in 3 months you gonna have a good product. I really would suggest you stop writing tests in this moment, takes time and probably in the future the code will change, which will require 2x work, but if you think you are fast doing this is okay. Another thing I would suggest is just comment features that are not finished and you think are not part of the primary feature, don't try to finish those things, just comment it out, if some customer asks for this in future you finish it. My approach is a bit radical, but I learned this way, customers will ask for stuff that matters at some point, if they think the primary feature is good enough, and for you to know if is good enough, you need to launch it, just make sure it works ;).

10x-dev 6y ago
Dumb question: how does one sell a SaaS in practice? Hypothetical scenario: solo engineer develops bitcoin trading platform. Wants to sell it. Then what? What steps does the engineer/founder take to sell this?
- overallduka 6y ago
  Sites like these: https://feinternational.com/ https://feinternational.com/, they guide you through the process, but you have to reach certain MRR(2k minimum I think), the price of the SAAS business is calculated using a multiple of the MRR(20x~48x).

rvba 6y ago

I think the guy has just low technical skills. He writes that he managed a team (that means other had to work), that he prefers team work (usually it means that someone else has to do the work). Then he started with the classic: previous code is bad so I rewrite it from scratch. Then came to a conclusion that his own code is bad and shouls be rewritten. And only then author had another conclusion: it was unlcear how the product should work. So they hired an UX person. Then we learned that moving buttons around requires back end changes (wtf?)... And then we learned that the author still didnt know how to make the main feature of the product. My guess: if they hired another programmer the other person would code it in few days. Author looks like a manager / team player - someone who never did anything on their own. Also I really loved the part about previous code being bad (classic) and rewriting everythig just to say that own code is bad too and didnt move the project at all. I wonder what part of the solution even works. Probably nothing apart from login window. Also the part where the author wrote that after coming back to previous work they had to do lots of frantic work... sounds like normal work. But author wasnt a manager anymore so the work had to be made: hence it was so painful. No more possibility to delegate the problem and do nothing all day. And real deadlines.