Hacker News Reader

Comment by 10x-dev | Hacker News Reader

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.

View on HN

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.

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.

Hasura is a game changing server technology. It handles postgres PostGIS and Json types really well.

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.

Hasura supports or will support MySQL soon (but is not 1 for 1 with PG in terms of features).

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.

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

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

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.

>> 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.

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.

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.

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.

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.

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.

> 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.

You're whinging about performance and then desire for a full featured ORM. Choose one.

The performance aspect is just illustrating of what a poor representation SQL is for machine-level use. And I'm by no means demanding a "full-fledged" ORM; even basic querying requires a layer or two above SQL to do cleanly.

All the databases seem to have database-specific ways. SQL is the least vulnerable to this. Obviously if you leave SQL for e.g. Mongo, then you could not have picked a more bespoke and unique interface. Notionally SQL is standardized, but who migrates databases anyway.

Network latency is the real performance drag, not string parsing.

I think JSON support will improve, but SQLAlchemy for example is ok with a common JSON interface over mySQL and Postgres. I am sure this will resolve itself in time, its just a bit new for SQL.

> Obviously if you leave SQL for e.g. Mongo, then you could not have picked a more bespoke and unique interface.

In principle yes; in practice you can expect to find full-featured drivers in all major languages, and anything higher-level that claims support for Mongo will also have support. Certainly even the most basic Mongo drivers will let you have things like collection columns.

> Network latency is the real performance drag, not string parsing.

Depends what kind of network, if any, is between the two endpoints. But the performance aspect is just illustrative of what a poor format for expressing machine-level queries it is.

> I think JSON support will improve, but SQLAlchemy for example is ok with a common JSON interface over mySQL and Postgres.

This works extremely well with Postgres. The MySQL one is I think just saving it as a text string, which may become a killer.

> In a modern RDBMS, 3/4 of the time to execute a pkey lookup is spent parsing the SQL string

These times are on the order of sub-milliseconds; about 0.1ms with PostgreSQL on my modest laptop with ~30 million row table.

You make it sound like it's some sort of horrible performance hog, but 0.1ms for parsing a dynamic language really isn't that bad. Actually fetching the row takes about 1ms (without anything cached, faster otherwise), so that's hardly "3/4th" either. With cache it's about 0.1ms, which is about half.

But in reality most queries are more complex, and the parsing time becomes negligible; even for a fairly complex query it's about 0.6ms, which is hardly worth thinking about if you consider that the query execution takes about 60ms.

> But in reality most queries are more complex, and the parsing time becomes negligible

Depends on your usage pattern. If you're actually doing a bunch of different ad-hoc aggregations (which is what SQL was designed for) then yes, query parse time is irrelevant. If you're using an RDBMS as a glorified key-value store (which is what most web applications tend to do) then it's very possible for pkey lookups to be the majority of your queries. (My point isn't really about performance, it's about SQL not being designed for that use style in general).

I have never seen SQL being used as a key-value store. That most web apps use it like that is an incredible claim to me. Do you have any source for that?

I've seen database profiling numbers from some of my clients, but obviously I can't publish those. To be clear all I'm claiming is that for most webapps the overwhelming majority of database queries are simple indexed column lookups, not that most webapps are putting document blobs in the database or using EAV style or anything like that.

Claiming that most queries are simple indexed columns lookups is a far cry from claiming most SQL databases are used as simple key-value stores.

Well, "key-value store" means different things to different people. If most queries are simple indexed column lookups then that carries my original point: query parse time is actually a significant proportion of overall datastore request processing time.

You do know that relational databases were predated by other kinds of databases and were far from standard for a long time, right?

They won their way to becoming a standard, for good reason.

All of which is still much better than rebuilding that stuff in your application layer, which is what you'll inevitably end up doing otherwise. Besides the fact that you'll likely do so in an incomplete and buggy way.

It's what you end up doing even with a relational database, because the database's built-in implementations aren't controllable enough. There's definitely space for a library that offers standard implementations of these things rather than everyone implementing it themselves from scratch, but applications need a lot more control over them than a traditional database gives them.

You end up rebuilding transactions, foreign keys, MVCC and similar features on relational db's? If so you're probably doing way to much work.

> You end up rebuilding transactions, foreign keys, MVCC and similar features on relational db's?

Yes, because the database-level builtins are too restricted; pretty much the only behaviour you can get out of them is "reject the change and throw away the data" which is almost never what you want, and requires you to keep the data around on the client side and hope that all clients implement recovery consistently. Think about the user-facing behaviour that you want when e.g. one user tries to join a group at the same time as another user deletes the group. It ends up being easier to implement the right thing without using database-level transactions and foreign keys.

> Think about the user-facing behaviour that you want when e.g. one user tries to join a group at the same time as another user deletes the group.

You join first and the group gets deleted or the group gets deleted and you can't join. I don't see the issue.

The audacity to say that when your very own blog includes an article titled "People who disagree with you aren't trying to make things complex. Maybe you're wrong."

There is a reason relational databases are the standard. It's one of the rare things in computer science actually based on mathematics.

> The audacity to say that when your very own blog includes an article titled "People who disagree with you aren't trying to make things complex. Maybe you're wrong."

What point are you trying to make? The point of that article was that the rhetoric about "simplicity" is unproductive, no-one makes a deliberate choice to use something they think is complex. But I didn't make that kind of argument.

> There is a reason relational databases are the standard. It's one of the rare things in computer science actually based on mathematics.

Relational databases are a very finely engineered hammer. But not everything is a nail.

This makes me think about how other people here feel about the arguments presented in this post. Personally, i actually agree with some of these points!

> difficulty deploying schema changes

Definitely agreed, even with tools like Flyway, Liquibase, dbmate or most of the framework provided options (such as Active Record Migrations for Rails and Doctrine for Symfony), most migrations still end up feeling brittle, because you oftentimes do things like renaming a column, or processing some data into a new format, or cleaning up old data etc. Well, you want to do that anyways, but then you realize that instead of simply renaming a column, you'll probably do a rolling migration for the apps that use the DB, therefore you need to create a new column that the app will write data into, then migrate all of the app instances to the new version and then clean up the old column, god forbid validations use the wrong column while this is going on. I don't think it's possible to work around problems like this with technologies like MongoDB either, since then dealing with missing data in an "old" version of a document would still be annoying. I don't know of any good solutions to address how data evolves over time, regardless of technology.

> difficulty sharding

Definitely agreed, in general it seems like most DBMS mostly scale vertically better than they do horizontally. For example, master-slave replication seems doable, but once you want to do master-master replication, you run into problems with latency and data consistency. There are some solutions like TiDB which attempt to give you a distributed database in a transparent way, without making you worry about its inner workings, but that only works until suddenly it doesn't. It seems like this problem affects most distributed systems and i'm not sure how to address it, short of making each new data entry reference the previous state, like CouchDB does with revisions ( https://docs.couchdb.org/en/stable/intro/api.html#revisions ) and even that won't always help.

> an awkward square-table model and a terrible query language

Partially agreed, SQL is pretty reasonable for what it does, despite its dialects being somewhat inconsistent, many of the procedural extensions being clunky and most of the in-database processing heavy systems that i've encountered being a nightmare from a debugging and logging perspective, though i guess that's mostly the fault of the tooling surrounding them. Discoverability can be a big problem if OTLT and EAV are heavily used ( https://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-bi... ) and foreign keys are not used. Window functions, analytical functions, partitioning and other functionality feels like it's implemented in unintuitive ways in some systems, but that could also be a question of familiarity and a steep learning curve.

> 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

Partially agreed, it can definitely happen, but being able to revert bad changes to the data and even test them in the first place sometimes feels like a godsend. Well, there should always be a local instance that's safe to break, but in practice that doesn't really come true often.

> Well, you want to do that anyways, but then you realize that instead of simply renaming a column, you'll probably do a rolling migration for the apps that use the DB, therefore you need to create a new column that the app will write data into, then migrate all of the app instances to the new version and then clean up the old column, god forbid validations use the wrong column while this is going on. I don't think it's possible to work around problems like this with technologies like MongoDB either, since then dealing with missing data in an "old" version of a document would still be annoying. I don't know of any good solutions to address how data evolves over time, regardless of technology.

IME the best way to do it is to build your system on stream transformation (i.e. Kafka) and then you can just produce the new representation in parallel, wait for it to catch up, migrate the readers over gradually and then eventually stop producing the old representation. That tends to be what you end up doing with a traditional RDBMS too, but if you're using something like Kafka then the pieces that you use are more normal parts of your workflow so it's less error-prone.

> It seems like this problem affects most distributed systems and i'm not sure how to address it, short of making each new data entry reference the previous state, like CouchDB does with revisions ( https://docs.couchdb.org/en/stable/intro/api.html#revisions ) and even that won't always help.

There are two approaches that I've known to work: 1. actual multiple concurrent versions as you say, with vector clocks or equivalent, forcing the clients to resolve conflicts if you're not using CRDTs - Riak was the best version of this approach, 2. having a clear shard key and allowing each partition to have its own "owner", making it clear what you do and don't guarantee across partitions - e.g. Kafka.

> Partially agreed, SQL is pretty reasonable for what it does, despite its dialects being somewhat inconsistent, many of the procedural extensions being clunky and most of the in-database processing heavy systems that i've encountered being a nightmare from a debugging and logging perspective, though i guess that's mostly the fault of the tooling surrounding them.

I wasn't talking about the fancy analytics so much as just the basic data model - e.g. having a collection-valued column is just way harder than it should be. Everything being nullable everywhere is also a significant pain.

>Definitely agreed, in general it seems like most DBMS mostly scale vertically better than they do horizontally.

NoSQL databases do nothing special to achieve horizontal scaling. They simply don't support transactions or atomic operations across documents. If that's what you want you can just choose an RDBMS with that behavior.

Sounds like vaporware to me. If there are any RDBMSes that support practical autoscaling, they're certainly less mature/established than e.g. Cassandra.

If you don't like relational databases what would you use instead? (And why?)

Without knowing the details of your use case, Cassandra. (Well, in reality Kafka, but that's a bigger leap). Consistent driver availability, easy horizontal scaling (not for performance to start with but for reliability), basic things like collection-valued columns can just work in a common-sense way, harder to shoot yourself in the foot with the consistency model, separate interfaces for fast key lookups and slow table scans so you don't mix them up.

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)

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... ;-)

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

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.

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.

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.

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!

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.

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.

Test suite is not free to create or maintain. To your example, for a product that isn't mature, a UI test suite is a waste of time and greatly increases the cost of UI changes.

This is what I don't get - a test suite saves me time. So, yes, it is free to create and maintain. Because it's much quicker to find regression bugs with automated testing than with manual testing. And this is massively more valuable when things are changing rapidly.

I think the core of what they're trying to get at is: let the users find those bugs. The business isn't large enough to focus on details, yet. In the future, when fixing bugs takes more time than making features, you should have the money to hire more hands and focus more on testing. If you don't, then you built too much product for too little clients which is a problem in and of itself ;-)

The cost/benefit isn't there in the beginning. All the bugs are either obvious, easy to find, or quickly discovered without a test suite. So save the time writing tests to stamp out more features the customer wants!

Adding features adds complexity. Features interact with each other in complex ways. If you add a feature and don't know quickly if it broke another feature, that costs time.

Letting the users find the bugs costs time - you have to talk to the user, replicate the bug report, find the failure, fix it, and then release. Finding that same bug 2 minutes after you wrote it (and before it got released) is massively quicker.

This feels like one of those "write code 16 hours a day to make more progress!" things that experience has taught me just doesn't work in practice. I feel like I'm making a lot of progress, but after about 10 hours most of the code I write is pure shite and needs to be rewritten the next day. I've found that it's actually way faster to quit coding after 8-10 hours rather than spend 2 hours the next day rewriting everything I wrote in the last 6 hours the day before.

> finding that same bug 2 minutes after you wrote it (and before it got released) is massively quicker.

That's not realistic.

Your last paragraph about overwork seems unrelated to TDD dogma.

That's because I was relating my personal experience building MVPs rather than spouting TDD dogma.

Tests cost money up front. Can you pay for those tests? You said you will pay for it in decreased costs once the business is running well.

Ok but how confident are you that your business will work out?

1%? you just increased your project costs 100 fold by doing tests.

50%? you just doubled your project costs by doing tests.

100%? Ok you are saving money, but if you are that confident then why haven't you gotten investors aboard that are convinced that doing it well from the start is a business edge?

You're essentially in prototyping phase. Inevitably you'll have to discard whole chunks of code, because your understanding of requirements/concept space changes. Then you have to discard both your code and your fine tests, wasting ~2x more time.

Yes, but writing tests isn't a huge cost if you're used to it. And once I've discarded that huge chunk of code, I immediately know what else I broke, rather than having to find it by testing manually.

If I have to write 100 lines of code to implement a feature, it really doesn't take me twice as long to write another 100 to test it. In most cases, writing the test alongside (or even before) the code helps with writing the code. I'd say writing a test adds maybe 25% to the time.

Knowing a year later than that code is still good, because that test still runs successfully, is easily worth that 25%

Of course I'm not saying 100% code coverage is worth it. Just the critical bits.

Thoughts of "a year later" and MVP mostly don't mix.

Agreed about coverage.

The mindset and goals are much different. At the extreme, a showstopper bug in an MVP is not a big deal - you have few (if any) customers and a glitch here and there won't make any difference in the long run.

Early stage tech founder should be either a cowboy programmer or a business-minded project manager, the type who ruthlessly kills projects and blows things up on a whim.

That's completely dependent on what kind of software you are writing. (And yeah, if you caught yourself automating UI tests, you are probably way too far.)

The best phrasing is the OP's in that "automated tests are anticorrelated to success" (so is posting on HN, by the way). That doesn't mean that for your exact case they are not essential, just that there is an statistic relation.

Indeed. The required mental shift became much more apparent to me in the recent months. I guess I'm slow :)

I don’t think that you are slow or not a good developer is the right conclusion. I think you focused on the wrong things. Like code coverage, CI, etc.

You mentioned of being afraid of your codebase exploding in other comment. You know code don’t really explode, right? The worst case is you will need some refactor down the road. Nothing worse than that.

Don't be too hard on yourself or you'll start doubting your own decisions too much. Everyone screws up some things, and nails some other ones.

Here's something that helps me with development. First, decide if it's a personal project for learning/fun, or if it's a commercial solution you are developing for someone else.

Personal projects get the cleanest code. I obsess with perfection. Max optimizations. Sexy tech. I'm Michelangelo and this us my Sisteen Chapel. John Carmack himself should take notes from that code. You get the idea. This project never ships though. 9/10 times I learn what I need and then it's just about grinding, I get bored and move on.

Commercial products or projects I really need to ship get a clean design, but thats all. I spend some time to design the foundation correctly, and from there, its an ugly, duct taped, unoptimized piece of crap that I can iterate quickly on.

Also, make sure the power dynamics in your team are correct. Dont get hired to write the code. Get hired to develop the technical solution. This way you can say "no" to things.

A pattern I've noticed much later in my early endeavors: if the business people (those writing the check) are also the product managers, the project is likely doomed. You know the type of person. They will insist on which features need to be there because having money automatically makes you an expert. They typically think of the end product as the MVP.

One last thing, internalize the following:

"Make it work. Make it right. Make it fast." <- in that order.

I say this, because you mentioned code coverage, and I would like to say that my opinion is one doesn't need unit tests for the first step.

Basically, screw the tests. I know, I know, how can anyone take me seriously when I say that. But, why do you need unit tests? To catch bugs in an MVP? Who expects rock solid, bug free MVPs? Maybe its to sleep better at night because code coverage is representative of code quality? We know it's not, so why bother?

Your MVP should be small enough that it's entire functionality is critical paths through the code. This means that every time you click through your product you are testing your code and you should be able to exercise most of it quickly and often. Unit tests are basically code that you have to maintain when something changes and it decreases your velocity. You don't want that, you just want to "make it work".

Will you eventually pay the price for not having unit tests initially? Yes, of course, but, if you designed your MVP correctly, this will either be never, because the product doesn't have market fit, or right at the time when you are getting product-market fit and are growing your team. At this time you will have a great idea of what functionality to add tests for. You won't even give a damn about the code coverage, because now is when you "make it right".

Either way, exclusions apply because software is hard. Good luck with your endeavors and keep coding ;)

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.

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.

> 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.

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).

> 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.

No way, maybe if you're working alone, but if there's even just two of us 'collaborating' via 'different folders and floppy disks' is going to slow me down, not speed me up.

It was hyperbole ffs, today it is more difficult to use floppy disks than Github. The point is that you dont need all the fancy stuff that more established companies with 10X-1000x more employees than you use.

Appreciate that re floppy disks specifically, I believe I did take it as intended, I was reacting to just sharing dumb directories - however they're pushed about - more than anything. I use git for things I work on alone, I find the ability to branch and stash etc. a net productivity improvement, not something that hampers me; add in collaborating with even one other person and I wouldn't even consider not using it, I'd honestly decline a job offer (well, everything has its price I suppose..!) over it, there's no way that's not a nightmare.

I have a tiny application. Yet it involves 5 containers. Some of the applications are a pain to install unless you go with a specific linux distribution and use their existing package. I don't have the time to manage all that crap through a labor intensive method or manage 5 separate servers when I can do it on one with containers. When I have to do things quick and dirty I just use a shell script with docker run and that's fine for 90% of projects because they don't pan out anyway. I can trivially switch to docker compose and then if I need scaling go to Kubernetes. It's a 100% solution. For the smallest prototype to large scale solutions. If you manage your servers manually you will either have to learn ansible which is just plain awful and difficult to use or you spend a lot of time doing everything yourself. Both cost time at the start of a project and many people don't have that time to waste on useless purism.

Disclaimer: I am building a product to address the same need for getting started with SaaS products as a kit, including Docker, Kubernetes, CI/CD and more: https://saasstarterkit.app/

I strongly agree with this. Investing into a quick setup for CI/CD in the beginning of a project pays of really quickly. Every time someone comes up with a "simpler" suggestion to deploy things, I find it always tricky and not-so-simple because of the following questions: - which machine do I deploy my code to? should I use an existing VM or should I get a new one? - what dependencies do I need to have on the machine? do I install them manually for each project? - how do I deploy multiple projects on this machine? what if the dependencies conflict? - how do I get the code to the instance? Should I use SCP, or Git, or some other method? - once the code is in the machine, how do I start it? how do I ensure it is running? - how do I securely expose it to the internet? - how do I serve multiple projects from the same instance?

Obviously, each of these questions have answers and they can be solved, potentially "simply" for some; but for myself, I found these to be way harder to deal with then a few lines of Kubernetes configuration. I use Docker for packaging the application, I build everything on GitLab CI, and just deploy to the same Kubernetes cluster for all of my projects. With this setup, I still use a single instance and have very low stable costs, and I can deploy 10+ projects on the same cluster since they have small load for now. Everything is standardized, and I can get to live in minutes even for a new project.

I believe the idea that these tools overcomplicate things need to ba taken on a case-by-case basis. For some, it works; for others, it won't, just like any other custom script or "simple" solution.

How did you go from "manual upload to file server" to Docker+Gitlab?

We've been shipping MVPs long before those were a thing.

./deploy.sh runs the commands you used to run manually.

What problem are you solving now with containers?

Listen to what you are saying: "It will take little time" and "it will be worth it down the line". These are bets. People get this wrong all the time.

Don't take the bet. That's happy path thinking. Take the shell script and 0 dependencies on external services and complex software.

> How did you go from "manual upload to file server" to Docker+Gitlab?

When I learned what I said: it takes little time to set it up and you reap the benefits. If you don’t know how to use it then it’ll take some time to learn, in such case I see value going with whatever you know.

>We've been shipping MVPs long before those were a thing.

That reasoning can be used with almost any technology and doesn’t tell anything.

>./deploy.sh runs the commands you used to run manually.

You went from “manually copying” to having a script with reproducible steps. You’re closer to CD than what you were thinking.

I think the rest of the comment doesn't need to be addressed.

Dockerfiles are just a few lines of shell script and a single shell command away from a fully reproducible image that can be run anywhere. They are also reusable across projects. This is a point where you can easily carry over your productivity if you are constantly starting new projects. Your latest project will be much further ahead on day 1 than your first project. Compare that to manually typing in commands on a server to set your production environment up. You'll forget things (massive drop in productivity) or have to write them down (massive drop in productivity). You'll redo the same stuff over and over (massive drop in productivity). For what gain? Just to stay purist?

You are taking the advice way too far. The advice is do things that increase your productivity and many things that increase productivity are also easy to setup once you know them. I'm not saying that you should learn containers for the sake of your startup. I am saying that tools you already know well often require very little effort to setup and pay dividends immediately.

> 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.

>"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.

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.

>"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.

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.

Counterpoint: that guy right there is your user. He's the guy you're selling to.

If he doesn't think you're worth the money... You can say gravity is wrong all you want, you're still hitting the floor.

It's rather unlikely that an anon on social media (HN) is "the guy you're selling to." Possible, but there are so many other motivations for a critical comment. "The guy you're selling to" is tangible and clearly has money to spend to solve a real problem.

If there is anything I've learned on social media, is that when you pitch an idea on Internet you can have hundreds of people swearing they'll buy your product day 1 if it has x, y or z. When the time comes to pull out the credit card however, suddenly everyone is gone.

He's the guy you're selling to.

He wants a different product with features that aren't in the MVP. He absolutely is not the person I'd be selling to. If it turns out that I can't find customers selling what I think is the right product for the market then I might have to pivot to build what he wants, but until then he's just someone who isn't my potential market right now.

Startup sales is about getting the customer to buy in before the product is exactly right for them. Changing your product to suit whatever the person in front of you wants is massively distracting, often bad for the product, and doesn't guarantee a sale anyway.

If he doesn't think you're worth the money..

The product not being what someone wants only means it's not worth the money for them. That doesn't mean the product isn't worth it for anyone. You need to find the person who wants what you have right now despite it not being perfect, and who is willing to pay for what you have on the basis that it'll become what they need in the future.

>"Why would you care about having unlimited access to an app that doesn't necessarily do what you need it to do?"

This is completely empty and made up argument. For every piece of software with perpetual license you can normally get evaluation version. Download and evaluate to your heart's content. Normally it is 30 days but I have not had one case in my live when vendor refused to extend eval period when asked.

>Answer either of 2 no and I am not buying it.

Well, this makes you irrelevant as a target customer in this heavy subscription/SaaS 2020 market.

There are others like you. But not many enough to make it worth focusing on them, plus they'd be more picky and have all kinds of other demands too that regular users don't have.

>"Well, this makes you irrelevant as a target customer in this heavy subscription/SaaS 2020 market."

My personal opinion is that this business model is simply not sustainable long term except for cases where the subscription model is a natural choice (Netflix for example). If I had to pay subscription for every piece of software I own I'd be ruined. With perpetual licenses however I only update / upgrade when I feel there is a benefit in it for me. Otherwise that old copy keeps working. I suspect I am not alone here.

As for not being relevant: so far I do not feel any lack of software offerings with perpetual licenses so allow me to disagree. I maybe irrelevant to your strict business model but not to the overall market.

>If I had to pay subscription for every piece of software I own I'd be ruined.

That's a very good point.

But also neither here, nor there. That's here the market seems to go, and it seems to indeed want us all ruined.

Or, rather, living paycheck to paycheck to pay those things...

I have this what I consider healthy attitude: I do not really give a flying fuck about what market wants. It seems that the guys like myself are still served really well. As for what happens in the future we'll see. I am tired to count how many times said marked had to correct its wet dreams.

Reply on news.ycombinator.com