How dirty is your MVP?
If you're not embarrassed by the first version of your product, you've launched too late
From the technical perspective, how much "far" in ignoring best practices and strict rules of coding/engineering are you ready to go in order to launch fast? Particular technical examples are warmly welcome! 🤓
You clearly need to make some compromises to iterate quickly.
For example implementing the unit tests and integration tests take as much time as developing the feature. So I show the feature to users ASAP, then if it survives it's worth spending the following week refactoring and executing units tests.
However anything related to data model and data structure is a pain to modify, so I try to get it right from the beginning.
Totally agree! Picking core tools and describing core data model is crucial. Unit/functional tests can be written later. By the moment of the MVP launch, manual testing will work almost perfectly, as there are not too many things to test.
Pretty much the only technical choice you can't undo is a public API.
In my last startup, I radically changed the design and features over time. I even ripped out the entire back-end and re-wrote it in another language... twice. As far as users were concerned there was no visible change, except the app got faster and more stable.
Just call it deprecated when a new one is ready 😉
Yep, anything that is pure front-end is fine to cut corners and clean-up later.
However for fintech app like cashcoach.io, we need to spend the time to follow all best security best practices and implement banking level standard.
Agree. Security and privacy are things that have no corners to cut.
Security is an area where there's no limit to how much you can invest in it, though. I've made thoughtful choices regarding security and have put some real effort into it, but I'm positive that if a major nation state wanted to crack it, they could.
The guidelines I'd follow are:
It's filthy.
Also, I reject the premise of "best practices". There's no such thing. There are just a bunch of people shouting about what they believe is best for their situation. There is no global "best". What's great for a new consumer startup is generally horrible for a large enterprise in a heavily regulated industry and visa versa.
I agree with this and would add it’s also very often an elitist position that can be quite unhelpful and a significant blocker to quick progress. 🐉
Often arises with people with 3-10 years of dev under their belt or “solution architects”. 🙅♂️
They typically over engineer the 💩 outta things and make what could be simple and easily replaceable/thrown away into a long term noose, which then encourages sunk cost fallacy at senior management level, especially so in those who dont know any different and who usually listen to these types of “architects” as if they’re some sort of Yoda. 🤡
Apologies for the rant. 😔
MVP is something that needs to be iterated on quickly so lock away features that won't change, and go dirty on those that will.
For me:
Specs/tests
Code cleanliness
Which tools are you using for this?
I use Nodejs for backend, and GraphQL for all my API - your stack might be different.
For me, instead of using the GraphQL Playground to test if each endpoint is working each time, I write integration tests in Jest which makes the actual query and snapshots and asserts the responses.
Ensuring that the API returns the correct payloads has saved me a lot of time when hooking up the frontend...
Same thing here. We use TypeScript and Apollo Server on our backend. Also trying to adapt such fancy things like Prisma https://www.prisma.io/
I tried Prisma - it's pretty good. I was sandwiched between Prisma 1 and 2 when they were launching the new version, so I decided to dump it.
But I been hearing great things about it so far, and this guy which I really respect seems to be using it in all his future projects: https://twitter.com/mxstbr/status/1181915864905506816
Thanks for the insight! We are eager to try Prisma in a battle. I particularly like it's TypeScript/GraphQL integration that comes out of the box.
Hmm, when I was using it, the graphql integration didn’t really matter, because I will still build ur my own resolvers.
Unless if you are using it with things like nexus-prisma, then it will help a lot.
You are right about Nexus. Our goal with Prisma ecosystem is to have GraphQL schema and TypeScript types in perfect sync.
I am sure you’ve seen it , but there’s also the typeorm + typegraphql combo.
My philosophy is to build prototypes dirty, just to prove that the idea works.
Then build whatever I just prove with the prototype as clean as possible, it can be a core part of a product, a library/service/interface that the product needs, following all the best practices and rules I know and I take the time to make it right.
This way, in my opinion, every piece of software is an MVP, but its more resilient to future change and it can cleanly evolve.
Prototypes must be thrown away always.
I have been told, by the people who did it, of a very profitable business spinning up using a single Excel spreadsheet as both data store and business logic implementation. Their user interface was a lot of telephones.
Pretty sure no-one here's at that level of grubbiness.
Do you know what kind of business?
I assume that they wouldn't be happy with me publishing the details in a public forum.
Now that I think of it, I wonder if that counts as serverless + nosql ...
https://frups.in
This dirty. Haha!
I'm trying out something new, where I don't care about technology for now and try to get things out the door as fast as possible. I'm basically working on a location directory and currently use WordPress and manual input to get something up and running easily.
Using an existing tool I'm comfortable with allows me to discover quickly what my app should & should not do. Because I don't spend much time on building each feature, I also don't mind throwing it out if it doesn't fit the product / MVP. When I have a more clear idea of what I want to build and I find starting from scratch necessary, it'll also allow better code to be written, because the 'discovery phase' already happened. And if I collect a meaningful amount of data already on WordPress, it's not that hard to take a database dump and write a one-off script to convert it to my new data model. Doing so would avoid having all manual input work thrown away.
I haven't had tests for my code in a long long time.
Hey Artem, I built the app Feelin app using react native and backend is built using nodejs, express, socket.io and mongodb it took me around 2 and a half months to build my own and after uploading the app in playstore I was excited but at the same time I was also embarrassed about the UI of the app that I made and the reason why am currently working for new update of the app. But still, I got around 200+ users and 500+ content created on the app in just 1 and a half months.
http://feal.in
On the first launch, I focused on Security, Features, and UI but after the launch I work on the backend to refactor my code and changes are done silently so I don't see any problem.
It's so dirty it can't come in side the house until it gets hosed off in the back yard twice.
Limit the scope of your MVP relentlessly just to launch by a set deadline.
NEVER reinvent the wheel. Use Bootstrap templates, JS plugins, NPM, PIP, etc.
Copy if you have to. Innovation is hard. Focus on executing.
Forgo unit/integration testing for now.
Put the features in place first, no matter how "hacky." Iterate later.
Join them together with duct tape, push it out to the world, and tell as many people as you can until they sign up and break your app, and then frantically fix those features they break while still asking for money to buy your app. ;)
This comment was deleted 3 years ago
I laughed.
My point is more about backend stuff. On the frontend of a product I guess you would want everything to look attractive and solid.
This comment was deleted 3 years ago
This comment was deleted 4 years ago
I really didn't mean that it's necessary to intentionally produce a shit code to launch fast, of course not. But I personally think that delivering value for users is much more important, than anything hidden under the hood. So, I would stick to some balance and reduce the quality bar for the MVP — lower test coverage, delegating to 3rd parties whatever possible, no performance optimizations and others.
Build it, test it, launch it! 😎 If they like it — polish it to the perfectness, but don't waste time on anything that no one will like.
This comment was deleted 4 years ago
Why would the moment have passed? People leave? Big deal. Just reach out to more new potential users who haven't heard of you.
This comment was deleted 4 years ago
I saw such situations as well. When it goes totally with no limits and no quality restrictions the result is terrible and not maintainable. But I'm talking more about a balance. Not about ignoring all the rules, but the "rules" that can be safely ignored at the moment.
Anyone can create a perfect thing when not limited in time. A few can create a good product on time.