Ask HN: Best way to build an MVP for non-technical founder
3 comments
I'd say the most important thing would be deciding if you want to fully outsource implementation, or if you want to 'ramp up' your coding to do it yourself. Starting a biz is stressful enough that you might not actually want to be responsible for implementation along with sales, customer support, accounting, etc.
For the MVP I'd recommend building on a tech stack you know/want to learn, or can hire consultants for easily (hopefully without breaking the bank!). Once you've identified the stack, I'd look for someone that not only has a solid background in the stack, but can also document/explain the application, provide mentoring (if needed), etc. Definitely someone that will be around to update/modify the MVP based on customer feedback or at the very least able to help architect/vet any changes you make yourself.
Depending on whether you're building a SaaS style app, or something installed locally by each client, you will have other questions to answer regarding hosting, support, software upgrades, etc.
In short, implementation is often the 'easiest' part of the job. Knowing what you want to build, and how you want to build it can be the real problem :-P
For the MVP I'd recommend building on a tech stack you know/want to learn, or can hire consultants for easily (hopefully without breaking the bank!). Once you've identified the stack, I'd look for someone that not only has a solid background in the stack, but can also document/explain the application, provide mentoring (if needed), etc. Definitely someone that will be around to update/modify the MVP based on customer feedback or at the very least able to help architect/vet any changes you make yourself.
Depending on whether you're building a SaaS style app, or something installed locally by each client, you will have other questions to answer regarding hosting, support, software upgrades, etc.
In short, implementation is often the 'easiest' part of the job. Knowing what you want to build, and how you want to build it can be the real problem :-P
I really appreciate your thoughtful answer!
Hire dev firm or individual > Make sure they can provide ongoing support
CTO cofounder > Need to consider upside/downside
Learn to code (or Bubble) > Need to consider my available time + decide on a language
I have started and stopped the Python 3 course on Code Academy probably 3-4 times over the years. I'm leaning that route. With GPT I bet I could knock something out in a couple months that would at least get me to a point where I can invite a few customers to kick the tires.
Hire dev firm or individual > Make sure they can provide ongoing support
CTO cofounder > Need to consider upside/downside
Learn to code (or Bubble) > Need to consider my available time + decide on a language
I have started and stopped the Python 3 course on Code Academy probably 3-4 times over the years. I'm leaning that route. With GPT I bet I could knock something out in a couple months that would at least get me to a point where I can invite a few customers to kick the tires.
So is it a CMMS (Computerized Maintenance Management System) or DMS (Document Management System)?
Something similar to offerings from EWorkOrders <https://eworkorders.com/cmms-industry-articles-eworkorders/c...> OR ARC <https://www.arcfacilities.com/product/om-documentation>
Whether you learn to build it yourself or get outside help, the optimizing for low-cost (no outside funding) usually means whether accepted or not a longer timeline to competitiveness. That timeline could potentially be reduced through significant scope narrowing in terms of provided features, platforms, etc.
If you think your niche customers will go for that narrowed scope and will accommodate a longer product timeline then you could build yourself but of course might go faster/smoother if you bring on outside help which may be pricey unless some heavy convincing of potential.
As for building in Bubble or from scratch that depends a lot on scope and product roadmap.
A Bubble app may be enough to provide value to customers while initially determining the right narrowed feature set, business model, pricing, etc. especially if deeper features might not be necessary for a few years (unless you take outside funding / accrue enough savings to expedite those features).
None of this is meant to dissuade, I have though been on projects that attempt to capture a niche that isn't fulfilled by current offerings only to discover the reason why is that, that niche of customers maybe aren't exactly sure what they want or only have enterprise SAAS offerings to compare to and really just want that product for cheaper.
Also there are numerous software products (especially SAAS) taken at face-value that don't look to be much more than a simple database and GUI but in reality, user access, legal requirements, privacy and security expectations, SLAs drastically increase the scope to be considered a viable option for companies.
All of this dependent of course on your unique knowledge of industry and problem-space and relationships with potential customers so hope this helps give some things to consider and best of luck!
Something similar to offerings from EWorkOrders <https://eworkorders.com/cmms-industry-articles-eworkorders/c...> OR ARC <https://www.arcfacilities.com/product/om-documentation>
Whether you learn to build it yourself or get outside help, the optimizing for low-cost (no outside funding) usually means whether accepted or not a longer timeline to competitiveness. That timeline could potentially be reduced through significant scope narrowing in terms of provided features, platforms, etc.
If you think your niche customers will go for that narrowed scope and will accommodate a longer product timeline then you could build yourself but of course might go faster/smoother if you bring on outside help which may be pricey unless some heavy convincing of potential.
As for building in Bubble or from scratch that depends a lot on scope and product roadmap.
A Bubble app may be enough to provide value to customers while initially determining the right narrowed feature set, business model, pricing, etc. especially if deeper features might not be necessary for a few years (unless you take outside funding / accrue enough savings to expedite those features).
None of this is meant to dissuade, I have though been on projects that attempt to capture a niche that isn't fulfilled by current offerings only to discover the reason why is that, that niche of customers maybe aren't exactly sure what they want or only have enterprise SAAS offerings to compare to and really just want that product for cheaper.
Also there are numerous software products (especially SAAS) taken at face-value that don't look to be much more than a simple database and GUI but in reality, user access, legal requirements, privacy and security expectations, SLAs drastically increase the scope to be considered a viable option for companies.
All of this dependent of course on your unique knowledge of industry and problem-space and relationships with potential customers so hope this helps give some things to consider and best of luck!
Hard to give advice with so little information regarding both the goals and the availability of resources. But I guess I would first ask if the MVP is even necessary? If the goal is to get funding for a startup and you have a good track record and a sound business plan, a slide deck could work. A UI prototype would be a plus.
You’re right, more details:
The goal is a working app that I can monetize, no outside funding desired. The app will be a document repository for facility managers who need to keep track of their equipment maintenance manuals. It’s a very specific niche, so not many customers but the pain is real. They have to keep the copies available in one place for regulatory purposes.
The goal is a working app that I can monetize, no outside funding desired. The app will be a document repository for facility managers who need to keep track of their equipment maintenance manuals. It’s a very specific niche, so not many customers but the pain is real.
Edited: more details