11 ms·

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

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.
  - cpursley 6y ago
    Hasura is a game changing server technology. It handles postgres PostGIS and Json types really well.
    - j45 6y ago
      It’s certainly one thing that made me wonder why I went in the direction of MySQL all those years ago.. from a modernization perspective it would be a bolt on for any existing Postgres db as well.
      - cpursley 6y ago
        Hasura supports or will support MySQL soon (but is not 1 for 1 with PG in terms of features).
- klodolph 6y ago
  The other reason I'd choose Postgres is because if it turns out you really want something more of a NoSQL style database, Postgres is still very competent.
  - NicoJuicy 6y ago
    Of you didn't knew this and doing c# Checkout the DocumentStore library: MartenDb It's documentation makes it pretty clear what postgress can do concerning this and event sourcing
- dSebastien 6y ago
  I think that it depends on the data model / use cases. When I joined the project, I didn't understand it enough to feel how relational the model really was. It only became apparent to me later on. And by then, it was much harder to replace it. CouchDB is really nice and has cool features, but for people used to SQL, its a very different beast. Querying is surprising in many ways (less so if you're used to MongoDB I guess). As you can guess, joins across documents and the like are not really great... and often necessary for relational data. The correct approach, assuming that we'd want to continue with it would be to denormalize the data much further (which we did not do so far), and perform data reconciliation... The offline-first case did sound convincing enough to me in the beginning, because we were targeting high level executives, which probably travel a lot more often than others, and still want to be able to work. But the world ain't static.. It's a different story in post-covid world :p
  - tictac-toe 6y ago
    All data is relational. If you think some data model is not relational then you haven't thought about the problem space enough :p The only valid reasons to choose non-relational databases are scalability and performance.
    - raphaelj 6y ago
      >> The only valid reasons to choose non-relational databases are scalability and performance. Agree 200%. And people seem to get a wrong idea of where this argument starts making sense. With the right indexes, I can easily handle 200req/s on my last SaaS running on a $50/m PostgeSQL. It's also significantly easier to move from a standardized relational model to a document DB than the opposite.
  - imtringued 6y ago
    CouchDB is often just used for simple cloud sync in combination with PouchDB. It's like having a Google Drive integrated into your application. If you do any complicated online querying it's simply not meant for that.
- forgingahead 6y ago
  One interesting heuristic for promoting engineers or making "more-senior" hires for me has been: 1. Curiosity and interest in new tech, so they are keeping abreast of developments and can think of modern best practices where useful. 2. Ability to ignore the new/sexy bits when it comes to implementation decisions, because the trade-off for stability/speed to implement is necessary in a growing company.
- jacquesm 6y ago
  The problem with specialized databases is that people use them as a starting point at the beginning instead of realizing that that is a premature optimization which they will likely come to regret later on. Initially you are much better off by choosing a standard relational database (Postgres,MySQL,MSSQL, pick your favorite flavor) and then, when you really have to you may have to add something that is specialized. So unless there are hard technical constraints right off the bat (which is almost never the case) stick to simple.
  - lmm 6y ago
    Relational databases are an extremely specialized kind of datastore that people only treat as "standard" because they've been around a long time. They're not better than the alternatives, and in many ways they're worse: by picking a relational database you're committing to difficulty deploying schema changes, difficulty sharding, an awkward square-table model and a terrible query language, and if you make the mistake of trying to use the transactional functionality that's the one actual selling point of those datastores then you're practically guaranteed to deadlock yourself in production at some point during your growth process.
    - tlarkworthy 6y ago
      Kinda with you until "terrible query language" as, in my mind, it's the best query language. You can also opt our of rigid schema by using JSON columns. Which I generally promote as a new best practice when the database is being uses as a dumb store for a smart application. It comes down to who should be the source of truth for the schema.
      - lmm 6y ago
        > Kinda with you until "terrible query language" as, in my mind, it's the best query language. It's a decent language for ad-hoc querying by humans; the problem is it's the only interface to the database that you get. It was never designed for machine use; in a modern RDBMS, 3/4 of the time to execute a pkey lookup is spent parsing the SQL string. Yes, prepared statements can help in some cases, but they come with their own overheads that make them difficult to use safely in a large system. > You can also opt our of rigid schema by using JSON columns. You can, but usually in a database-specific way, and support for that in drivers and especially at the ORM level is pretty spotty.
rlonn 6y ago
To me, it looks as if he wasn't obsessed with the problem. He did everything except work on the product, from what I can tell, and my guess is that he either wasn't interested in the problem, and not disciplined enough to work on it anyway, or perhaps he suffers from impostor syndrome and don't want to work on the actual product because he thinks he'll fail. (of course, not bothering about the product leads to bigger failure eventually)
- dSebastien 6y ago
  I was probably not obsessed enough with it. It's hard to say, really. I tried hard to create a sound data model and technical solution to support the development, but often felt like we needed this and that refactoring to be able to move forward. Impostor syndrome is indeed strong... ;-)
  - aprdm 6y ago
    Others have said already but switching cloud providers, kubernetes, ci/CD, couch... it seems more like you were more interested in playing with tech than building a company
  - Kwantuum 6y ago
    What the comment you're replying to is saying, is that if you were deeply obsessed with the problem, you wouldn't have to think twice to make trade-offs. If the problem you're solving really needs solving right now, you will always make the trade-off that gets your solution into the world faster. You're not obsessed with the fact that teams all over the world could have less sucky meetings if they had an even incomplete version of your product in hand right now.
  - PeterStuer 6y ago
    Reading your essay it feels like you were obsessed with the product's artefacts, the methodology, the tech stack, the hosting, the scalability, the suportabiliry..., far more than wth the solution and getting the first sale. All of these are good qualities, but if you then do not have a product owner to push back and force you to deliver fast and cut every corner imaginable, you can indeed find yourself in endless development rewrites and optimisations. I have seen quite a few startups up close in Belgium, and I'm fairly confident that you would be horrified by the code base and operations of the ones that are succeeding. P.S. Smartschool seems to be triving in the Belgian school system.
dSebastien 6y ago
Thanks. I think that you're spot on. I've probably been more obsessed about "the way it should be" rather than "what's the shortest path to get our first clients using it". I suppose that it's a newbie mistake; out of fear. Part of me couldn't accept the idea of delivering something that would explode and that I wouldn't be able to support in production. It's still something I fear, especially when I look at our code coverage, even though I do care about the quality of what I create.. As you say, switching from CouchDB to PGSQL wouldn't be easy at all. And yep, agreed about schools and restaurants, you're probably right.
- aprdm 6y ago
  You might be surprised about how much code underpinning our society has no tests at all, how many huge companies place no value on test coverage. And it all mostly works just fine. It might be even the right decision some times to not spend time in tests!
- dannyw 6y ago
  It sounds like you might not have the right mindset for being a technical startup founder. Unit tests and code coverage is anticorrelated with success. With a startup, your goal is to iterate the fastest. You cannot afford to be spending more than 1 day of time on your continuous deploy system before you have your first paying client. Given the size to your team, you should also have been spending near zero time on documentation. Documentation should be in the form of sticky notes and Slack messages. I think you’re very talented technically, but you should not work on startups until you are able to emulate more of the successful technical cofounder patterns. If your code and processes can scale to 100x of your time expected volume, this is almost universally a sign that you have failed to optimise for what matters. This also goes even if you’re building something like AWS. AWS engineers do not build over-engineered systems that can handle 100d of its expected volume.
  - marcus_holmes 6y ago
    I find this weird. Automated testing has saved me so much time. If I don't have tests and make a change, I have to manually go through a whole set of checks to make sure I didn't break anything. If I have a test suite, it will tell me in 2 minutes if I broke anything. The thing I'm working on at the moment has tests on the backend but not on the UI. I can definitely say the UI work is slower because of the lack of tests.
AnHonestComment 6y ago
I agree generally, but ‘docker run’ is the modern extract a ZIP file.
FpUser 6y ago
>"If you can't sell that, then you are either not solving the right problem" Interesting. When I act as a client and looking to buy me some software the first things I am looking for: 1) Does it have perpetual license for at least the version I am about to buy. 2) Can it work offline? Answer either of 2 no and I am not buying it. Well this of course excludes things like Netflix. The product I make offers either either perpetual license or subscriptions so the customer gets to choose. So far perpetual license revenue exceeds that of subscriptions.
- kristianp 6y ago
  Typical hacker news answer, There's always someone to come along and have the exact opposite opinion. :) But seriously, I can understand the preference for offline, non-subscription software, it's often cheaper and it's often faster. Non subscription doesn't provide for a steady revenue stream for the developer, however.
  - FpUser 6y ago
    >"Non subscription doesn't provide for a steady revenue stream for the developer, however." Developer is not entitled to that "steady revenue stream". Keep working and releasing new products / features that customers are willing to pay for and you'll be fine.
- onion2k 6y ago
  Why would you care about having unlimited access to an app that doesn't necessarily do what you need it to do? That's what we're talking about here - all the MVP should do is the absolute minimum to solve the problem it sets out to solve, and as a customer you don't know if it actually does that until either you've tried it, or you have validation from other people who've tried it. No one should be worried about perpetual licenses or offline support for an app that hasn't proven it even solves the problem in a viable way yet. If those things are key to your purchasing decision then you probably ought to be buying from established businesses with proven products and good support, and that is definitely not any startup I know. I suspect your comment betrays the fact that you think the first version of a startup's software is the first finished and stable version. That's the main problem here. Startups need to be selling long before they're at that stage.
1337shadow 6y ago
I agree with your point, but when it comes to tech choices I would say it depends on the experience, the point is that for an MVP you should go with things you know well and are efficient with. One can setup a Gitlab pipeline with Docker and docker-compose and continuous deployment in something like 7 hours, when pretty used to it. In this case, automating migrations can be done by running the migration script in Docker image command, and then you can have a proper RDMS that you have to add to docker-compose, if you've gone for a development framework that supports migration of course, which I believe you should in general. For example, I made electeez.com which is now the less insecure online voting solution that I know of, thanks to homomorphic encryption library microsoft/electionguard and Django, in 3 weeks, add another week for a proper TDD rewrite that accounts for security of the endpoints, at the pace of 3 work days per week. Of course, mvp.css helped a lot too! If I were to implement a better webdesign, my next step would be to use the Material Components Web Components served by Skypack and just follow the Material Design Guidelines so in another iteration of 3 days have something that's a bit more beautiful ... but for sure, beauty doesn't matter for an MVP, only usability does.
outime 6y ago
I agree with the main point but: >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. Ok, let's accept that K8s is overkill most of the times. But containerization and CI/CD? If you've some experience with it you know it's something that takes little time and money to set up (e.g. GitLab CI) and you get tons of benefits - you don't need to get super fancy either. To me it sounds like the time waster would be doing what you describe, specially because it's so easy to mess it up after you do it a bunch of times on a single day. I used to do that when I started with PHP several years ago (replace scp-ing with FTP and git with cvs or svn) but IMHO it's not worth it once you deploy your product live.
- reader_mode 6y ago
  > But containerization and CI/CD? If you've some experience with it you know it's something that takes little time and money to set up (e.g. GitLab CI) and you get tons of benefits - you don't need to get super fancy either This - CI/CD during development pays off so fast it's not worth skipping.
  - dSebastien 6y ago
    I don't regret setting up CI; it has saved us quite some time already with broken PRs (haven't tried CD, and I won't before we sell this thing :p).
- cambalache 6y ago
  > But containerization and CI/CD? It is. For a very small startup, with not outside funding, everything that is not DIRECTLY related with A) Getting a paying customer. B) Launching, is a complete waste of time. Please note this is not the only game in town (if you are Boston Dynamics by all means take all the time in the world to make those robots awesome) but if you are Yet Another Small Saas company for the love of god, launch, launch, launch.This is the game you chose to play.I dont care if your control version system are different folders and your backup are floppy disks, just launch and see if you can get people giving money to you for your product.
Aeolun 6y ago
> The world is filled with people who regret rewriting the persistence layer for an MVP under pressure. I think this may be true for people that switch from noSQL to NoSQL or from RDB to NoSQL, but very few that switch from NoSQL to RDB.

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.
- cpursley 6y ago
  Hasura is a game changing server technology. It handles postgres PostGIS and Json types really well.
  - j45 6y ago
    It’s certainly one thing that made me wonder why I went in the direction of MySQL all those years ago.. from a modernization perspective it would be a bolt on for any existing Postgres db as well.
    - cpursley 6y ago
      Hasura supports or will support MySQL soon (but is not 1 for 1 with PG in terms of features).
klodolph 6y ago
The other reason I'd choose Postgres is because if it turns out you really want something more of a NoSQL style database, Postgres is still very competent.
- NicoJuicy 6y ago
  Of you didn't knew this and doing c# Checkout the DocumentStore library: MartenDb It's documentation makes it pretty clear what postgress can do concerning this and event sourcing
dSebastien 6y ago
I think that it depends on the data model / use cases. When I joined the project, I didn't understand it enough to feel how relational the model really was. It only became apparent to me later on. And by then, it was much harder to replace it. CouchDB is really nice and has cool features, but for people used to SQL, its a very different beast. Querying is surprising in many ways (less so if you're used to MongoDB I guess). As you can guess, joins across documents and the like are not really great... and often necessary for relational data. The correct approach, assuming that we'd want to continue with it would be to denormalize the data much further (which we did not do so far), and perform data reconciliation... The offline-first case did sound convincing enough to me in the beginning, because we were targeting high level executives, which probably travel a lot more often than others, and still want to be able to work. But the world ain't static.. It's a different story in post-covid world :p
- tictac-toe 6y ago
  All data is relational. If you think some data model is not relational then you haven't thought about the problem space enough :p The only valid reasons to choose non-relational databases are scalability and performance.
  - raphaelj 6y ago
    >> The only valid reasons to choose non-relational databases are scalability and performance. Agree 200%. And people seem to get a wrong idea of where this argument starts making sense. With the right indexes, I can easily handle 200req/s on my last SaaS running on a $50/m PostgeSQL. It's also significantly easier to move from a standardized relational model to a document DB than the opposite.
- imtringued 6y ago
  CouchDB is often just used for simple cloud sync in combination with PouchDB. It's like having a Google Drive integrated into your application. If you do any complicated online querying it's simply not meant for that.
forgingahead 6y ago
One interesting heuristic for promoting engineers or making "more-senior" hires for me has been: 1. Curiosity and interest in new tech, so they are keeping abreast of developments and can think of modern best practices where useful. 2. Ability to ignore the new/sexy bits when it comes to implementation decisions, because the trade-off for stability/speed to implement is necessary in a growing company.
jacquesm 6y ago
The problem with specialized databases is that people use them as a starting point at the beginning instead of realizing that that is a premature optimization which they will likely come to regret later on. Initially you are much better off by choosing a standard relational database (Postgres,MySQL,MSSQL, pick your favorite flavor) and then, when you really have to you may have to add something that is specialized. So unless there are hard technical constraints right off the bat (which is almost never the case) stick to simple.
- lmm 6y ago
  Relational databases are an extremely specialized kind of datastore that people only treat as "standard" because they've been around a long time. They're not better than the alternatives, and in many ways they're worse: by picking a relational database you're committing to difficulty deploying schema changes, difficulty sharding, an awkward square-table model and a terrible query language, and if you make the mistake of trying to use the transactional functionality that's the one actual selling point of those datastores then you're practically guaranteed to deadlock yourself in production at some point during your growth process.
  - tlarkworthy 6y ago
    Kinda with you until "terrible query language" as, in my mind, it's the best query language. You can also opt our of rigid schema by using JSON columns. Which I generally promote as a new best practice when the database is being uses as a dumb store for a smart application. It comes down to who should be the source of truth for the schema.
    - lmm 6y ago
      > Kinda with you until "terrible query language" as, in my mind, it's the best query language. It's a decent language for ad-hoc querying by humans; the problem is it's the only interface to the database that you get. It was never designed for machine use; in a modern RDBMS, 3/4 of the time to execute a pkey lookup is spent parsing the SQL string. Yes, prepared statements can help in some cases, but they come with their own overheads that make them difficult to use safely in a large system. > You can also opt our of rigid schema by using JSON columns. You can, but usually in a database-specific way, and support for that in drivers and especially at the ORM level is pretty spotty.

rlonn 6y ago

To me, it looks as if he wasn't obsessed with the problem. He did everything except work on the product, from what I can tell, and my guess is that he either wasn't interested in the problem, and not disciplined enough to work on it anyway, or perhaps he suffers from impostor syndrome and don't want to work on the actual product because he thinks he'll fail. (of course, not bothering about the product leads to bigger failure eventually)

dSebastien 6y ago
I was probably not obsessed enough with it. It's hard to say, really. I tried hard to create a sound data model and technical solution to support the development, but often felt like we needed this and that refactoring to be able to move forward. Impostor syndrome is indeed strong... ;-)
- aprdm 6y ago
  Others have said already but switching cloud providers, kubernetes, ci/CD, couch... it seems more like you were more interested in playing with tech than building a company
- Kwantuum 6y ago
  What the comment you're replying to is saying, is that if you were deeply obsessed with the problem, you wouldn't have to think twice to make trade-offs. If the problem you're solving really needs solving right now, you will always make the trade-off that gets your solution into the world faster. You're not obsessed with the fact that teams all over the world could have less sucky meetings if they had an even incomplete version of your product in hand right now.
- PeterStuer 6y ago
  Reading your essay it feels like you were obsessed with the product's artefacts, the methodology, the tech stack, the hosting, the scalability, the suportabiliry..., far more than wth the solution and getting the first sale. All of these are good qualities, but if you then do not have a product owner to push back and force you to deliver fast and cut every corner imaginable, you can indeed find yourself in endless development rewrites and optimisations. I have seen quite a few startups up close in Belgium, and I'm fairly confident that you would be horrified by the code base and operations of the ones that are succeeding. P.S. Smartschool seems to be triving in the Belgian school system.

dSebastien 6y ago

Thanks. I think that you're spot on. I've probably been more obsessed about "the way it should be" rather than "what's the shortest path to get our first clients using it". I suppose that it's a newbie mistake; out of fear. Part of me couldn't accept the idea of delivering something that would explode and that I wouldn't be able to support in production. It's still something I fear, especially when I look at our code coverage, even though I do care about the quality of what I create.. As you say, switching from CouchDB to PGSQL wouldn't be easy at all. And yep, agreed about schools and restaurants, you're probably right.

aprdm 6y ago
You might be surprised about how much code underpinning our society has no tests at all, how many huge companies place no value on test coverage. And it all mostly works just fine. It might be even the right decision some times to not spend time in tests!
dannyw 6y ago
It sounds like you might not have the right mindset for being a technical startup founder. Unit tests and code coverage is anticorrelated with success. With a startup, your goal is to iterate the fastest. You cannot afford to be spending more than 1 day of time on your continuous deploy system before you have your first paying client. Given the size to your team, you should also have been spending near zero time on documentation. Documentation should be in the form of sticky notes and Slack messages. I think you’re very talented technically, but you should not work on startups until you are able to emulate more of the successful technical cofounder patterns. If your code and processes can scale to 100x of your time expected volume, this is almost universally a sign that you have failed to optimise for what matters. This also goes even if you’re building something like AWS. AWS engineers do not build over-engineered systems that can handle 100d of its expected volume.
- marcus_holmes 6y ago
  I find this weird. Automated testing has saved me so much time. If I don't have tests and make a change, I have to manually go through a whole set of checks to make sure I didn't break anything. If I have a test suite, it will tell me in 2 minutes if I broke anything. The thing I'm working on at the moment has tests on the backend but not on the UI. I can definitely say the UI work is slower because of the lack of tests.

AnHonestComment 6y ago

I agree generally, but ‘docker run’ is the modern extract a ZIP file.

FpUser 6y ago

>"If you can't sell that, then you are either not solving the right problem" Interesting. When I act as a client and looking to buy me some software the first things I am looking for: 1) Does it have perpetual license for at least the version I am about to buy. 2) Can it work offline? Answer either of 2 no and I am not buying it. Well this of course excludes things like Netflix. The product I make offers either either perpetual license or subscriptions so the customer gets to choose. So far perpetual license revenue exceeds that of subscriptions.

kristianp 6y ago
Typical hacker news answer, There's always someone to come along and have the exact opposite opinion. :) But seriously, I can understand the preference for offline, non-subscription software, it's often cheaper and it's often faster. Non subscription doesn't provide for a steady revenue stream for the developer, however.
- FpUser 6y ago
  >"Non subscription doesn't provide for a steady revenue stream for the developer, however." Developer is not entitled to that "steady revenue stream". Keep working and releasing new products / features that customers are willing to pay for and you'll be fine.
onion2k 6y ago
Why would you care about having unlimited access to an app that doesn't necessarily do what you need it to do? That's what we're talking about here - all the MVP should do is the absolute minimum to solve the problem it sets out to solve, and as a customer you don't know if it actually does that until either you've tried it, or you have validation from other people who've tried it. No one should be worried about perpetual licenses or offline support for an app that hasn't proven it even solves the problem in a viable way yet. If those things are key to your purchasing decision then you probably ought to be buying from established businesses with proven products and good support, and that is definitely not any startup I know. I suspect your comment betrays the fact that you think the first version of a startup's software is the first finished and stable version. That's the main problem here. Startups need to be selling long before they're at that stage.

1337shadow 6y ago

I agree with your point, but when it comes to tech choices I would say it depends on the experience, the point is that for an MVP you should go with things you know well and are efficient with. One can setup a Gitlab pipeline with Docker and docker-compose and continuous deployment in something like 7 hours, when pretty used to it. In this case, automating migrations can be done by running the migration script in Docker image command, and then you can have a proper RDMS that you have to add to docker-compose, if you've gone for a development framework that supports migration of course, which I believe you should in general. For example, I made electeez.com which is now the less insecure online voting solution that I know of, thanks to homomorphic encryption library microsoft/electionguard and Django, in 3 weeks, add another week for a proper TDD rewrite that accounts for security of the endpoints, at the pace of 3 work days per week. Of course, mvp.css helped a lot too! If I were to implement a better webdesign, my next step would be to use the Material Components Web Components served by Skypack and just follow the Material Design Guidelines so in another iteration of 3 days have something that's a bit more beautiful ... but for sure, beauty doesn't matter for an MVP, only usability does.

outime 6y ago

I agree with the main point but: >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. Ok, let's accept that K8s is overkill most of the times. But containerization and CI/CD? If you've some experience with it you know it's something that takes little time and money to set up (e.g. GitLab CI) and you get tons of benefits - you don't need to get super fancy either. To me it sounds like the time waster would be doing what you describe, specially because it's so easy to mess it up after you do it a bunch of times on a single day. I used to do that when I started with PHP several years ago (replace scp-ing with FTP and git with cvs or svn) but IMHO it's not worth it once you deploy your product live.

reader_mode 6y ago
> But containerization and CI/CD? If you've some experience with it you know it's something that takes little time and money to set up (e.g. GitLab CI) and you get tons of benefits - you don't need to get super fancy either This - CI/CD during development pays off so fast it's not worth skipping.
- dSebastien 6y ago
  I don't regret setting up CI; it has saved us quite some time already with broken PRs (haven't tried CD, and I won't before we sell this thing :p).
cambalache 6y ago
> But containerization and CI/CD? It is. For a very small startup, with not outside funding, everything that is not DIRECTLY related with A) Getting a paying customer. B) Launching, is a complete waste of time. Please note this is not the only game in town (if you are Boston Dynamics by all means take all the time in the world to make those robots awesome) but if you are Yet Another Small Saas company for the love of god, launch, launch, launch.This is the game you chose to play.I dont care if your control version system are different folders and your backup are floppy disks, just launch and see if you can get people giving money to you for your product.

Aeolun 6y ago

> The world is filled with people who regret rewriting the persistence layer for an MVP under pressure. I think this may be true for people that switch from noSQL to NoSQL or from RDB to NoSQL, but very few that switch from NoSQL to RDB.