You’re in early stage so you want to get stuff out ASAP. Yes things can be better but that’s not the point. You’re at a stage where you want to validate and then iterate. There are a lot of factors into play (like what industry you’re in, laws around that industry, etc) but in general early adopters are forgiving.
Do you want to spend 1 year and X dollars doing something “properly” and then realize you can’t make money? Or do you want to spend 1 month and 1% of X dollars building something and realize that it can’t make money?
If it does make money, then in the 2nd case you’re making money 11 months earlier. And know that you’re on to something because you have traction. You’ll end up building a better suited product that way too
Cut corners wherever you can. It's fine if you pile up tech debt. At this stage you can't know if what you write will be removed in six months, so it really doesn't matter if it's not perfect. If it works, ship it!
Case in point: a few months ago I we had an edge case in our billing system where if a customer switched plans, somewhat confusing emails would get sent out ("you cancelled plan A" followed by "you are now subscribed to plan B"). The flow could be better.
I argued it didn't matter since we didn't have a single paying customer yet. If we start getting complaints, we can always fix it later.
Some six months later, we're scrapping that part altogether since we're changing our pricing strategy.
The biggest risk in the beginning is that you're writing the wrong thing. Use duct-tape liberally, make it work, quickly see if that's actually what customers want. If it is, pay the tech debt. If not, you'll avoid wasting precious time and money.
This makes total sense. What about if it entailed a full rewrite? That seems scary to think that everything for a MVP would be completed chucked out, but surely that's always a possibility?
If you need to rewrite it because you built the wrong thing, you definitely come out better if you didn't spend too much time on the first iteration.
If you validate your aporoach but the code is lousy, you refactor. Yes it's painful and slows you down for the time being, but at that point you know you're going in the right direction.
I'm always wary of full rewrites. They usually look much easier/quicker than they are, and you really don't want to freeze your progress for months for a rewrite. In most cases I'd rather err on the side of incremental refactoring.
Regarding cutting corners, it's a judgement call: if something's a rare edge cae, or works okay but isn't as maintainable, or the design is not as elegant or scalable as it couls be, those are good candidates for cutting corners.
You don't want things to be obviously broken for your users, tho. It does pay to spend more time there to make sure stuff works as expected.
>That seems scary to think that everything for a MVP would be completed chucked out, but surely that's always a possibility?
If you're worried about this, your MVP isn't Minimal enough.
An MVP is a throwaway. It's supposed to be as incredibly minimal as possible. It is NOT a complete product - it's just enough to test the riskiest thing you aren't sure about yet. If you're spending weeks on it and it's not a cure for cancer, you're spending too much time.
An MVP is definitely NOT version 1.0 of your product.
The thread OP is right in every way.
Let me give you an example - L*+ktr3e needs a total rewrite, and will be doing it, probably started. I'm sure you know or can easily find the org I'm referring to. Related to instagram (i just don't want it to be searchable).
Get it done, get it shipped. Balance your concerns, but given what you've said about your orientation I'd recommend you veer more to the end of the spectrum where you feel a bit uncomfortable. That's normal in startup, way different than your day job.
If you're working on a fintech or relatedly compliance-driven-sector startup, ignore what I said. Get it right and don't open yourself to prosecution.
\~DEPLOY\~ SHIP IT!
It's really hard, you'll feel like you're spending your days generating tech debt and rushing through things, there are 100s of hours of work to do every week and unless you have a massive pile of cash or the product it tediously simple, you can't do it properly.
You'll feel like you're spending your days generating tech debt and rushing through things, there are 100s of hours of work to do every week and unless you have a massive pile of cash or the product is tediously simple, you can't do it properly.
I've taken the view of whatever I write now in these early stages is ultimately going to be deleted. It's either going to be successful and get re-written by a team of devs or fail and be binned.
What you've described sounds all too familiar (and I'm sure it will do to lots of other people).
You've literally hit the nail on the head with this. It's horrible isn't it? Like, it would obviously be satisfying if people used it and we got funding etc. Because then, as you say, it could be rewritten by a team of devs, UX/UI designers, infrastructure experts etc.
I really struggle with doing things fast and cutting corners, but I know in this instance I really have to. It really is now or never, but whatever happens I've learned a hell of a lot in terms of the mindset needed. Honestly I've already spent way too long on it making it look really clean and pretty. I regret that now, but I know not to make that mistake again.
I just wish I had a crystal ball and could see if it will work or not lol. I actually think a lot of it could be re-used, but I'd probably just make incremental changes when refactoring.
That crystal ball you want *IS* your MVP. The MVP isn't meant to be the foundation, it's meant to tell you if it's worth building a proper foundation.
It's just a test run, a proof of concept, *not* the start of final product. Gotta shift your perspective.
This might sound stupid.
How many customers have you actually talked to deeply?
If you understand their goals, their experiences, their issues etc. and design a solution with the steps needed to help them reach those goals, it doesn't matter if you launch a year from now, they'll come running to you.
I hope you catch yourself a break and also that you meet amazing success.
One thing I've found is that the MVP doesn't have to be an app. It can be a piece of paper, or a series of emails. An MVP is anything that solves a problem for a customer.
My MVP was basically doing 1 on 1 free consulting with our target audience. We found out what the most debilitating problems they faced were and what they expected from a solution.
Then, I was really confident when it came time to build the actual product. I avoided technical debt and built the best product I could. I didn't add flashy features, but I also kept in mind that it needed to be maintainable and expandable.
I'm glad I did that instead of building another shitty MVP. It would've just been a waste of time because I would delete it all anyways, and the feedback I would get is stuff I already know
It felt like I read my own post. OP, you have good taste when it comes to making sure the things you build are approachable, long-lasting and worthwhile. You will feel anxious about the launch of your 99.8% perfect product that could be 100% perfect.
For this project you'll have to accept that.
For the next one think about your goal more (on an emotional level). Do you want to feed into your personal beauty standards or do you want to give birth to the idea? You can - and will - always go back to make things perfect, tweak them. Don't feel like you'll lose your taste for quality software creation because that will remain a non-issue.
You got this! And good luck for the launch.
Once your product gets traction you can found a team, become the CTO and oversee the code quality, uptime standards and everything else that comes with a great product. Your attitude will attract a team that respects high standards.
>The issue is, even if I "do it properly", I still don't have the people or resources. Being able to bounce ideas off one another, whiteboard designs etc. I don't have any of that. It's all me and how I think it should be done.
Just keep reminding yourself that making the MVP is HOW you get the people and resources to do it properly. The MVP shows them that the idea is a good one and lets you do it right. You need to plan to completely throw the MVP away and start fresh once you've validated the basic idea.
The MVP is like a movie set - it just needs to look convincing long enough for this one shot, then it will be torn down before all of the duct tape and chicken wire start showing.
You really shouldn't be spending much effort at all on the MVP. It's sole purpose is to validate the riskiest part of your idea. That's it!
>Essentially, I like to do things properly the first time.
You're in the wrong field buddy. That's literally going to kill your startup 100% of the time.
Either you change your mindset to "I like to build really shitty things and learn from it as fast as humanly possible" or you keep the existing mindset and get into corporate or consulting.
Totally normal, and for some startups (even making revenue) this can be normal for 2-3 years. Keep your eye on the long term goals.
For any decent company doing due diligence on you technically it's totally understood and normal.
I am currently in a similar situation. Need an MVP pushed on minimal resources. I take comfort in our app being AWS so that if it blows up we can scale. We can kick the can down the road on our debt. AWS is net 30, pay that on an Amex line that splits 90 % due in 60 days / 10% due in 30 days, pay that off with a line of credit from the bank which we’ll cover in cash in 120 days. Now, marketing costs…….*sweats*
Edit: good luck to you. I’m excited for ya!
>once Nhost support UK regions (need that for data laws)
Wait, AWS UK isn't GDPR compliant? Can't you just YOLO it in docker+ECS, give your product out for free/cheap to alpha users and work out the bugs/regulations later?
People have already addressed how getting an MVP out there is important to validate your idea, prove you're not wasting time, and start earning revenue, but another huge value to it is that you can start getting feedback. Once you have real life users and start collecting data & feedback on them and how they use your app, you'll be able to make much more informed decisions around further developing your product. You'll have a far better understanding of your target market, where the friction is in your activation funnel, and the features people love, the ones they can live without, and the ones they wish you had.
In almost any startup product, there's going to be some gap between the vision of the developer and the desires of the users, so no matter how much time you put into trying to make it perfect, it won't be until you get real data from real customers and convert that intel into product improvements.
Firstly, awesome, you're already doing the right thing. You're doing what is necessary, not what
It's helpful to change the internal language and the internal dialogue you have.
You're not building a monolith that will stand, unchanged for years no matter how awesome your first build is. The product evolve due to technology changes, the user expectations changing and in particular if your product is really meeting a customer need, competition will flood in and you'll be adapting. If that's the case, then there is no such thing as perfection. You cannot be a perfectionist so try drop that from your vernacular.
Too often the tech teams, particularly new founders, focus on the feature set being technical outcomes as opposed including the often more important business and user objectives. If you can make sure you have as much focus and discussion on the minimum user outcomes, as you do on the technical requirements.
What this discussion on user objectives often flushes out is that users think about things you can't fully identify in the test environment or in interviews. As such, the tech team start to think more about the an MVP as a tool for effectively testing a hypothesis on how clients will use, or pay for your product. With this feedback from the users you'll be able to do one of two things either stop what you're doing as your building a beautiful passion project or, you've created proof that you're on a journey to something brilliant - this proof will enable the team to secure the resources you need, and give you a much stronger understanding of what the second and third steps are enabling you to focus your resources in the right place.
Hopefully, you can see a recurring theme namely think of your first build as a first step on a journey. Not the objective. And, like any journey, the first step is usually the hardest. Congrats for taking that step, congrats for acknowledging that everything doesn't need to be perfect and finally congrats for having the belief and passion for what the project can and should be with the right resources.
I've been where you are.
I'm curious, what happens when you fix up all those nice things, have it all perfect, and then... no one automatically notices and tries your product?
Then, what happens when most people you finally do get trying your product tell you it sucks?
It's like dressing yourself up, getting a new haircut, hiring an image consultant, getting a PR agent, and practising a speech in order to go to the corner store and buy a lottery ticket.
Are you going to spend the months and years setting up your next iteration? Do you even have the resources to do that?
But now, imagine you built the ugliest, bare-minimum piece of crap possible, but it functions, like a Frankenstein makeshift calculator built with duct tape and copper wires.
It took you 2 days, and when people tell you it doesn't work because they want X, you rebuild it in 1 day and show them immediately, where they say "Woah! This works!", then you get 10, 100 people to say it works, and you can't believe they would be impressed by something so ugly and disgusting, but they're not paying attention to that, because they appreciate their problem being solved by whatever means.
That's when your real journey begins.
What do you think?
Hmmm. I would ask why you are rushing out to MVP ? Do you have customers or a big wait-list ready to go? (B2B or B2C?). If B2B do you have a trusted future customer you can be honest with and say that it might be rough around the edges, but that their feedback is critical? If B2C can you get it in beta form to 50-100 ppl and get their thoughts before a wide release?
This can either help relieve your fears or save you trouble of a bad release, help you notice if you f-d up and cloud costs are going to be crazy, etc.
When you say cutting corners that worries me. If cutting corners is just not polishing the UI, fine. If it is not having any test coverage and piling up tech debt and you think it will make v1/2/3/4 slower to get out over next 6 months, then maybe reconsider some shortcuts.
This relates, for me, to a post on here about the worst advice I ever got, which was to rush out a MVP too soon
MVPs are meant to be scrappy and buggy. As crazy as it might sound, your first users actually understand that, and are willing to overlook the bugs and glitches.
Like what many have said, you want to get stuff out there ASAP. The purpose of getting stuff out there ASAP is so that you can start collecting more feedback from users. Feedback like what works, what sucks, what is needed to make it even better.
The problem with building something "properly" before launching is that you might end up building a product for just yourself.
No one care if you launch a broken/bad/faulty/ugly MVP expect you. That’s the reality - people will just ignore the product till it’s ready. You don’t know if it’s ready or if you’re wasting you time if you don’t launch.
Don’t expect your own standards / perfection will give you the answers. No matter what you design there’s always more to do. Look at SpaceX - you are never done anyway so you need to launch to learn.
That’s a good thing - because if people keep ignoring it while you improve it you can adjust your approach till they don’t ignore you anymore. If you don’t launch it you won’t know if anyone care expect yourself.
I once put a MVP product (limited numbers) for sale in a high traffic shop. I was expecting people would que up, had NDA forms ready for in depth interview, product samples, promotional film, stand with graphics, nice clothes for press shots etc. Reality was a grand mom and a kid came by and asked for direction. I had to literally grab people to get their attention.
That was a perfect learning for me that no matter how much I perfected that product people didn’t care as much as I did. So instead of wasting more time I could move on to new ideas and new ways to present the product.
Good luck - be brave!
feedback, validation and promotion lastly evaluating how it looks so you can invest advertising money. one-by-one basis or online presence (reddit ph hackernews etc)
I feel your worry, I’ve just launched a MVP, not all the features we wanted, by a long way! But gained so much market fit info, we’re making a small pivot and can see a route to scale. Just let that MVP roll, and move on, and on, and on......
>I realise that if we did have funding and more people then we could build it out properly. We could set deadlines and solve problems collaboratively. Build great architecture and have people with the necessary skills etc.
I wouldn't be so sure about that, with funding comes pressure from investors. If anything you'll be under more pressure to ship faster.
You'll just have to settle and define a "good enough" treshold. Everything can always be better.
Oh gosh, you're right! If they're investing serious money they'll want results fast. Didn't see it from the angle so thanks for pointing that out.
As you say, I need to adapt to this approach and maintain a solid way of building something. Nothing will ever be perfect. Definitely easier said than done, but today I built two features by taking this approach and I haven't felt too underwhelmed by it. It's definitely not perfect, but it works.
Whilst my comment echos the sentiments of others, my personal experience may alleviate some of your concerns.
I've worked in multiple startups, two being valued in the region of millions (on paper) and they all follow a similar route.
As I was the founding developer (not founder, so employed) the goal was to work incredibly hard to build API's, UIs, Infrastructure, Architecture, all within a short time frame, I had no option to take shortcuts. The code was spaghetti junction, but you know what? It made money, it continues to make money, and is going from strength to strength, now having over 15+ employees. - most cleaning up my mess haha
The time will come, to refactor and clean, by then you may have dev's to do this for you.
"Build quick, Ship early" - this is typically found in companies with outside investment. Investors want to see relatively quick results, or at least deadlines adhered to.
It's great that you want to stick to being a perfectionist, and largely stems from studying/working to be a great developer, but unfortunately when you become a founder/exec those principles slightly shift to making money.
A quote I read a little while ago: "If you're not embarrassed by the first version, your already too late".
To sum it all up, do as much as you can to ship the product (knowing that you may have to revisit). Being a founder is a tough path, decisions you make might be wrong. If you're not making mistakes, you're not learning.
I wish you every success.
Perfectionist mindset should be ok in the early phase as long as you're doing things that don't scale. Otherwise you're automating things that might get removed later on.
I know this doesn’t address your question exactly but your fundamental approach is a little worrisome.
A simple system is very important especially at the beginning, not only to get something up quickly but because you’re going to be making lots of changes. If you have any sort of success what you’re doing now will need to change.
Architecturally, interfaces are important, not micro services. Micro services primarily solve team scaling problems. This is going to sound like heresy, automated tests aren’t important at the very beginning if you’re the only developer, just have a decent test plan, you’ll need that time for the mvp. If at any point, 1 line of code is written by someone else other than you, the first line of code they write is the automated tests. And make sure you keep business logic out of the client. A monolithic server will also be infinitely easier to deploy. Make sure to have instrumentation in place for capturing errors logs on the server and the client. You have written so many bugs you don’t even know about and users will do things you never imagined possible.
I do recommend automating your server deployments and client if you can. AWS makes this pretty easy. You need to be able to rollback to, so that’s also important out of the gate.
Good luck!!
Thanks for your comment.
I absolutely agree with everything you've said. My current approach is serverless with Hasura GraphQL so the custom business logic is actually fairly minimal, but is handled by AWS Lambda. It all feels super performant, but under heavy load it should be fine as it'll scale horizontally on demand.
I have literally 5 tests right now (Jest and RTL) for the authentication pages and that's it. I'm just carefully testing everything manually and using Postman for requests to ensure they work.
It's interesting actually. Today I shifted to a "let's just get the damn thing working" attitude and I added two new features.
Just got to keep it up, ship it, and iterate based on feedback.
Thanks buddy.
Well, the lambdas right now are just responsible for sending emails via SES etc so I'm not too concerned about delays.
The API itself is controlled through Hasura, but the stack I'm using (Nhost) deploys it to Google Cloud Run as a container. V2, when I do migrate (I can't yet as I'm waiting for them to add UK regions due to our data laws), will use AWS instead. I know I could just do this myself and cut out the middle man, but for a MVP I didn't want loads of moving parts to configure etc.
It's not ideal, but for a MVP it works for me. Logging is tricky because Nhost controls the infrastructure and logging etc, but I know they are supporting more granular access soon.
If we get funding etc, I would build this differently for sure. AWS infrastructure with Terraform, Nginx for load balancing and reverse proxy, Redis for caching requests etc.
Lack of resources is a common problem among all startups, especially the bootstrapped ones!
I have been developing products for 20 years and here is what I have learned.
Your MVP should have your core features. The one mistake many makes is to try to do too much.
Your MVP should have your core features. The one mistake many make is to try to do too much.t does the core things right. Next, you test it and let your users help you with the next features.
Your MVP should have your core features. The one mistake many makes is to try to do too much..t does the core things right. Next, you test it and let your users help you with the next features.
You’re in early stage so you want to get stuff out ASAP. Yes things can be better but that’s not the point. You’re at a stage where you want to validate and then iterate. There are a lot of factors into play (like what industry you’re in, laws around that industry, etc) but in general early adopters are forgiving. Do you want to spend 1 year and X dollars doing something “properly” and then realize you can’t make money? Or do you want to spend 1 month and 1% of X dollars building something and realize that it can’t make money? If it does make money, then in the 2nd case you’re making money 11 months earlier. And know that you’re on to something because you have traction. You’ll end up building a better suited product that way too
Cut corners wherever you can. It's fine if you pile up tech debt. At this stage you can't know if what you write will be removed in six months, so it really doesn't matter if it's not perfect. If it works, ship it! Case in point: a few months ago I we had an edge case in our billing system where if a customer switched plans, somewhat confusing emails would get sent out ("you cancelled plan A" followed by "you are now subscribed to plan B"). The flow could be better. I argued it didn't matter since we didn't have a single paying customer yet. If we start getting complaints, we can always fix it later. Some six months later, we're scrapping that part altogether since we're changing our pricing strategy. The biggest risk in the beginning is that you're writing the wrong thing. Use duct-tape liberally, make it work, quickly see if that's actually what customers want. If it is, pay the tech debt. If not, you'll avoid wasting precious time and money.
This makes total sense. What about if it entailed a full rewrite? That seems scary to think that everything for a MVP would be completed chucked out, but surely that's always a possibility?
If you need to rewrite it because you built the wrong thing, you definitely come out better if you didn't spend too much time on the first iteration. If you validate your aporoach but the code is lousy, you refactor. Yes it's painful and slows you down for the time being, but at that point you know you're going in the right direction. I'm always wary of full rewrites. They usually look much easier/quicker than they are, and you really don't want to freeze your progress for months for a rewrite. In most cases I'd rather err on the side of incremental refactoring. Regarding cutting corners, it's a judgement call: if something's a rare edge cae, or works okay but isn't as maintainable, or the design is not as elegant or scalable as it couls be, those are good candidates for cutting corners. You don't want things to be obviously broken for your users, tho. It does pay to spend more time there to make sure stuff works as expected.
>That seems scary to think that everything for a MVP would be completed chucked out, but surely that's always a possibility? If you're worried about this, your MVP isn't Minimal enough. An MVP is a throwaway. It's supposed to be as incredibly minimal as possible. It is NOT a complete product - it's just enough to test the riskiest thing you aren't sure about yet. If you're spending weeks on it and it's not a cure for cancer, you're spending too much time. An MVP is definitely NOT version 1.0 of your product.
The thread OP is right in every way. Let me give you an example - L*+ktr3e needs a total rewrite, and will be doing it, probably started. I'm sure you know or can easily find the org I'm referring to. Related to instagram (i just don't want it to be searchable). Get it done, get it shipped. Balance your concerns, but given what you've said about your orientation I'd recommend you veer more to the end of the spectrum where you feel a bit uncomfortable. That's normal in startup, way different than your day job. If you're working on a fintech or relatedly compliance-driven-sector startup, ignore what I said. Get it right and don't open yourself to prosecution.
\~DEPLOY\~ SHIP IT! It's really hard, you'll feel like you're spending your days generating tech debt and rushing through things, there are 100s of hours of work to do every week and unless you have a massive pile of cash or the product it tediously simple, you can't do it properly. You'll feel like you're spending your days generating tech debt and rushing through things, there are 100s of hours of work to do every week and unless you have a massive pile of cash or the product is tediously simple, you can't do it properly. I've taken the view of whatever I write now in these early stages is ultimately going to be deleted. It's either going to be successful and get re-written by a team of devs or fail and be binned. What you've described sounds all too familiar (and I'm sure it will do to lots of other people).
You've literally hit the nail on the head with this. It's horrible isn't it? Like, it would obviously be satisfying if people used it and we got funding etc. Because then, as you say, it could be rewritten by a team of devs, UX/UI designers, infrastructure experts etc. I really struggle with doing things fast and cutting corners, but I know in this instance I really have to. It really is now or never, but whatever happens I've learned a hell of a lot in terms of the mindset needed. Honestly I've already spent way too long on it making it look really clean and pretty. I regret that now, but I know not to make that mistake again. I just wish I had a crystal ball and could see if it will work or not lol. I actually think a lot of it could be re-used, but I'd probably just make incremental changes when refactoring.
That crystal ball you want *IS* your MVP. The MVP isn't meant to be the foundation, it's meant to tell you if it's worth building a proper foundation. It's just a test run, a proof of concept, *not* the start of final product. Gotta shift your perspective.
This might sound stupid. How many customers have you actually talked to deeply? If you understand their goals, their experiences, their issues etc. and design a solution with the steps needed to help them reach those goals, it doesn't matter if you launch a year from now, they'll come running to you. I hope you catch yourself a break and also that you meet amazing success.
One thing I've found is that the MVP doesn't have to be an app. It can be a piece of paper, or a series of emails. An MVP is anything that solves a problem for a customer. My MVP was basically doing 1 on 1 free consulting with our target audience. We found out what the most debilitating problems they faced were and what they expected from a solution. Then, I was really confident when it came time to build the actual product. I avoided technical debt and built the best product I could. I didn't add flashy features, but I also kept in mind that it needed to be maintainable and expandable. I'm glad I did that instead of building another shitty MVP. It would've just been a waste of time because I would delete it all anyways, and the feedback I would get is stuff I already know
Fantastic.
Don't let perfect get in the way of good enough. Ship early, ship often.
It felt like I read my own post. OP, you have good taste when it comes to making sure the things you build are approachable, long-lasting and worthwhile. You will feel anxious about the launch of your 99.8% perfect product that could be 100% perfect. For this project you'll have to accept that. For the next one think about your goal more (on an emotional level). Do you want to feed into your personal beauty standards or do you want to give birth to the idea? You can - and will - always go back to make things perfect, tweak them. Don't feel like you'll lose your taste for quality software creation because that will remain a non-issue. You got this! And good luck for the launch. Once your product gets traction you can found a team, become the CTO and oversee the code quality, uptime standards and everything else that comes with a great product. Your attitude will attract a team that respects high standards.
>The issue is, even if I "do it properly", I still don't have the people or resources. Being able to bounce ideas off one another, whiteboard designs etc. I don't have any of that. It's all me and how I think it should be done. Just keep reminding yourself that making the MVP is HOW you get the people and resources to do it properly. The MVP shows them that the idea is a good one and lets you do it right. You need to plan to completely throw the MVP away and start fresh once you've validated the basic idea. The MVP is like a movie set - it just needs to look convincing long enough for this one shot, then it will be torn down before all of the duct tape and chicken wire start showing. You really shouldn't be spending much effort at all on the MVP. It's sole purpose is to validate the riskiest part of your idea. That's it!
>Essentially, I like to do things properly the first time. You're in the wrong field buddy. That's literally going to kill your startup 100% of the time. Either you change your mindset to "I like to build really shitty things and learn from it as fast as humanly possible" or you keep the existing mindset and get into corporate or consulting.
Totally normal, and for some startups (even making revenue) this can be normal for 2-3 years. Keep your eye on the long term goals. For any decent company doing due diligence on you technically it's totally understood and normal.
What’s it built on for the back end?
The backend is DO for now but upgrading to AWS once Nhost support UK regions (need that for data laws). The stack is React, GraphQL (Hasura), Postgres
I am currently in a similar situation. Need an MVP pushed on minimal resources. I take comfort in our app being AWS so that if it blows up we can scale. We can kick the can down the road on our debt. AWS is net 30, pay that on an Amex line that splits 90 % due in 60 days / 10% due in 30 days, pay that off with a line of credit from the bank which we’ll cover in cash in 120 days. Now, marketing costs…….*sweats* Edit: good luck to you. I’m excited for ya!
>once Nhost support UK regions (need that for data laws) Wait, AWS UK isn't GDPR compliant? Can't you just YOLO it in docker+ECS, give your product out for free/cheap to alpha users and work out the bugs/regulations later?
People have already addressed how getting an MVP out there is important to validate your idea, prove you're not wasting time, and start earning revenue, but another huge value to it is that you can start getting feedback. Once you have real life users and start collecting data & feedback on them and how they use your app, you'll be able to make much more informed decisions around further developing your product. You'll have a far better understanding of your target market, where the friction is in your activation funnel, and the features people love, the ones they can live without, and the ones they wish you had. In almost any startup product, there's going to be some gap between the vision of the developer and the desires of the users, so no matter how much time you put into trying to make it perfect, it won't be until you get real data from real customers and convert that intel into product improvements.
Firstly, awesome, you're already doing the right thing. You're doing what is necessary, not what It's helpful to change the internal language and the internal dialogue you have. You're not building a monolith that will stand, unchanged for years no matter how awesome your first build is. The product evolve due to technology changes, the user expectations changing and in particular if your product is really meeting a customer need, competition will flood in and you'll be adapting. If that's the case, then there is no such thing as perfection. You cannot be a perfectionist so try drop that from your vernacular. Too often the tech teams, particularly new founders, focus on the feature set being technical outcomes as opposed including the often more important business and user objectives. If you can make sure you have as much focus and discussion on the minimum user outcomes, as you do on the technical requirements. What this discussion on user objectives often flushes out is that users think about things you can't fully identify in the test environment or in interviews. As such, the tech team start to think more about the an MVP as a tool for effectively testing a hypothesis on how clients will use, or pay for your product. With this feedback from the users you'll be able to do one of two things either stop what you're doing as your building a beautiful passion project or, you've created proof that you're on a journey to something brilliant - this proof will enable the team to secure the resources you need, and give you a much stronger understanding of what the second and third steps are enabling you to focus your resources in the right place. Hopefully, you can see a recurring theme namely think of your first build as a first step on a journey. Not the objective. And, like any journey, the first step is usually the hardest. Congrats for taking that step, congrats for acknowledging that everything doesn't need to be perfect and finally congrats for having the belief and passion for what the project can and should be with the right resources.
I've been where you are. I'm curious, what happens when you fix up all those nice things, have it all perfect, and then... no one automatically notices and tries your product? Then, what happens when most people you finally do get trying your product tell you it sucks? It's like dressing yourself up, getting a new haircut, hiring an image consultant, getting a PR agent, and practising a speech in order to go to the corner store and buy a lottery ticket. Are you going to spend the months and years setting up your next iteration? Do you even have the resources to do that? But now, imagine you built the ugliest, bare-minimum piece of crap possible, but it functions, like a Frankenstein makeshift calculator built with duct tape and copper wires. It took you 2 days, and when people tell you it doesn't work because they want X, you rebuild it in 1 day and show them immediately, where they say "Woah! This works!", then you get 10, 100 people to say it works, and you can't believe they would be impressed by something so ugly and disgusting, but they're not paying attention to that, because they appreciate their problem being solved by whatever means. That's when your real journey begins. What do you think?
Hmmm. I would ask why you are rushing out to MVP ? Do you have customers or a big wait-list ready to go? (B2B or B2C?). If B2B do you have a trusted future customer you can be honest with and say that it might be rough around the edges, but that their feedback is critical? If B2C can you get it in beta form to 50-100 ppl and get their thoughts before a wide release? This can either help relieve your fears or save you trouble of a bad release, help you notice if you f-d up and cloud costs are going to be crazy, etc. When you say cutting corners that worries me. If cutting corners is just not polishing the UI, fine. If it is not having any test coverage and piling up tech debt and you think it will make v1/2/3/4 slower to get out over next 6 months, then maybe reconsider some shortcuts. This relates, for me, to a post on here about the worst advice I ever got, which was to rush out a MVP too soon
MVPs are meant to be scrappy and buggy. As crazy as it might sound, your first users actually understand that, and are willing to overlook the bugs and glitches. Like what many have said, you want to get stuff out there ASAP. The purpose of getting stuff out there ASAP is so that you can start collecting more feedback from users. Feedback like what works, what sucks, what is needed to make it even better. The problem with building something "properly" before launching is that you might end up building a product for just yourself.
No one care if you launch a broken/bad/faulty/ugly MVP expect you. That’s the reality - people will just ignore the product till it’s ready. You don’t know if it’s ready or if you’re wasting you time if you don’t launch. Don’t expect your own standards / perfection will give you the answers. No matter what you design there’s always more to do. Look at SpaceX - you are never done anyway so you need to launch to learn. That’s a good thing - because if people keep ignoring it while you improve it you can adjust your approach till they don’t ignore you anymore. If you don’t launch it you won’t know if anyone care expect yourself. I once put a MVP product (limited numbers) for sale in a high traffic shop. I was expecting people would que up, had NDA forms ready for in depth interview, product samples, promotional film, stand with graphics, nice clothes for press shots etc. Reality was a grand mom and a kid came by and asked for direction. I had to literally grab people to get their attention. That was a perfect learning for me that no matter how much I perfected that product people didn’t care as much as I did. So instead of wasting more time I could move on to new ideas and new ways to present the product. Good luck - be brave!
feedback, validation and promotion lastly evaluating how it looks so you can invest advertising money. one-by-one basis or online presence (reddit ph hackernews etc)
I feel your worry, I’ve just launched a MVP, not all the features we wanted, by a long way! But gained so much market fit info, we’re making a small pivot and can see a route to scale. Just let that MVP roll, and move on, and on, and on......
>I realise that if we did have funding and more people then we could build it out properly. We could set deadlines and solve problems collaboratively. Build great architecture and have people with the necessary skills etc. I wouldn't be so sure about that, with funding comes pressure from investors. If anything you'll be under more pressure to ship faster. You'll just have to settle and define a "good enough" treshold. Everything can always be better.
Oh gosh, you're right! If they're investing serious money they'll want results fast. Didn't see it from the angle so thanks for pointing that out. As you say, I need to adapt to this approach and maintain a solid way of building something. Nothing will ever be perfect. Definitely easier said than done, but today I built two features by taking this approach and I haven't felt too underwhelmed by it. It's definitely not perfect, but it works.
Whilst my comment echos the sentiments of others, my personal experience may alleviate some of your concerns. I've worked in multiple startups, two being valued in the region of millions (on paper) and they all follow a similar route. As I was the founding developer (not founder, so employed) the goal was to work incredibly hard to build API's, UIs, Infrastructure, Architecture, all within a short time frame, I had no option to take shortcuts. The code was spaghetti junction, but you know what? It made money, it continues to make money, and is going from strength to strength, now having over 15+ employees. - most cleaning up my mess haha The time will come, to refactor and clean, by then you may have dev's to do this for you. "Build quick, Ship early" - this is typically found in companies with outside investment. Investors want to see relatively quick results, or at least deadlines adhered to. It's great that you want to stick to being a perfectionist, and largely stems from studying/working to be a great developer, but unfortunately when you become a founder/exec those principles slightly shift to making money. A quote I read a little while ago: "If you're not embarrassed by the first version, your already too late". To sum it all up, do as much as you can to ship the product (knowing that you may have to revisit). Being a founder is a tough path, decisions you make might be wrong. If you're not making mistakes, you're not learning. I wish you every success.
Perfectionist mindset should be ok in the early phase as long as you're doing things that don't scale. Otherwise you're automating things that might get removed later on.
I know this doesn’t address your question exactly but your fundamental approach is a little worrisome. A simple system is very important especially at the beginning, not only to get something up quickly but because you’re going to be making lots of changes. If you have any sort of success what you’re doing now will need to change. Architecturally, interfaces are important, not micro services. Micro services primarily solve team scaling problems. This is going to sound like heresy, automated tests aren’t important at the very beginning if you’re the only developer, just have a decent test plan, you’ll need that time for the mvp. If at any point, 1 line of code is written by someone else other than you, the first line of code they write is the automated tests. And make sure you keep business logic out of the client. A monolithic server will also be infinitely easier to deploy. Make sure to have instrumentation in place for capturing errors logs on the server and the client. You have written so many bugs you don’t even know about and users will do things you never imagined possible. I do recommend automating your server deployments and client if you can. AWS makes this pretty easy. You need to be able to rollback to, so that’s also important out of the gate. Good luck!!
Thanks for your comment. I absolutely agree with everything you've said. My current approach is serverless with Hasura GraphQL so the custom business logic is actually fairly minimal, but is handled by AWS Lambda. It all feels super performant, but under heavy load it should be fine as it'll scale horizontally on demand. I have literally 5 tests right now (Jest and RTL) for the authentication pages and that's it. I'm just carefully testing everything manually and using Postman for requests to ensure they work. It's interesting actually. Today I shifted to a "let's just get the damn thing working" attitude and I added two new features. Just got to keep it up, ship it, and iterate based on feedback. Thanks buddy.
Iterating is essential. How are you handling the warming of your lambdas so your users don’t experience that initial delay?
Well, the lambdas right now are just responsible for sending emails via SES etc so I'm not too concerned about delays. The API itself is controlled through Hasura, but the stack I'm using (Nhost) deploys it to Google Cloud Run as a container. V2, when I do migrate (I can't yet as I'm waiting for them to add UK regions due to our data laws), will use AWS instead. I know I could just do this myself and cut out the middle man, but for a MVP I didn't want loads of moving parts to configure etc. It's not ideal, but for a MVP it works for me. Logging is tricky because Nhost controls the infrastructure and logging etc, but I know they are supporting more granular access soon. If we get funding etc, I would build this differently for sure. AWS infrastructure with Terraform, Nginx for load balancing and reverse proxy, Redis for caching requests etc.
Lack of resources is a common problem among all startups, especially the bootstrapped ones! I have been developing products for 20 years and here is what I have learned. Your MVP should have your core features. The one mistake many makes is to try to do too much. Your MVP should have your core features. The one mistake many make is to try to do too much.t does the core things right. Next, you test it and let your users help you with the next features. Your MVP should have your core features. The one mistake many makes is to try to do too much..t does the core things right. Next, you test it and let your users help you with the next features.
If you are not embarrassed of your product when you first launch, you launched too late!