Reasons not to do this: - you don't really understand the full complexity of the domain or regulatory environment yourself - you don't have the funding available to commit to not only the development team but also the infrastructure to support them (tooling, cloud environments, security team, policies to support this, technical writer, ...) - you're not prepared to pay for top talent (assuming you can even judge it, see the point below). Starting something from scratch successfully requires a really experienced team who understand how to model and build things well. Who know how to build in sucha way that frequently changing things effectively become configuration rather than code etc etc. Most likely this means people who have 10+ years in the industry and preferably people with some product and industry experience. - you expect this will be a one-time cost hit and then effectively free in perpetuity; software is expensive to maintain, requires ongoing security patching, keeping up with library and technology updates, and ongoing commitment even if from a business perspective nothing is charging. - you don't have experts on hand who you can afford to have spending more of their time than you think is reasonable with your development team explaining in detail all of the lessons you've learnt from the current poorly performing software and what they really need. - you're not prepared for it to take at least four times as long and be four times as painful as even your worst-case initial estimates. - you're in an environment that requires eg. purchase of vendor libraries and/or integration to proprietary platforms and this impacts the economics of boutique development - you're highly regulated and software you build/use has additional complications like certification/audit/... requirements - especially if you don't fully understand or can't communicate this effectively to the build team - you don't know how to judge the competence or experience of your founding technical team; this will be critical to your success - more critical than almost anything else. One bad hire can derail your entire effort. - you want an entity that you're bound to contractually and that you can sue for remedy when things go really wrong. And they will go wrong. Of course there are lots of reasons to try to build the software yourself too, but hopefully the above gives a few counter points to think about.