You’ve got this fantastic idea. This product that’s going to solve a big problem for a lot of people, but there is one thing holding you up! The answers to the big tech questions;
What language should I write this in?
What frameworks should I be using?
How can I build this to support the millions of users who will come flooding in when the realise how amazing my idea is?
Most product developers I know love to plan for the future, they want to build products that are simple, neat and logical, and will stay that way regardless of future shifts in scope and demand. Their heart is in the right place, after all, an hour of planning saves months of going in the wrong direction, right? Well, not really. Not with a product that doesn’t exist yet.
I love this anecdote from Art & Fear (thanks codinghorrors.com!)
The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”.Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work — and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.
The moral of the story is that if you want perfection, quantity always trumps quality. If you want to create the best software, you have to write it, then write it again. If it’s still not good, write it again! This is true of all software, but even more so for a product which needs to be moulded to the needs of its future users, who at the early stage of a startup are probably nothing more than a speculative group of strangers.
The funny thing is, when your writing software for a new startup, it’s even easier to forget this rule because you have even more unknowns to take into consideration — scaling, cost of infrastructure, future hiring, technical competencies of the team, speed of initial development, speed of changes… And because there is so much to consider, people get caught up on trying to make all of the decisions at once.
So what’s the answer? For me, it’s this;
What language should I use?
The one you are most competent in. Is it fast, does it scale, is it easy to hire in — It doesn’t matter. The most important problem you need to solve is whether you can validate your idea in the real world. Is there a market for it, and are people willing to give you money for your solution?
What frameworks should I use?
Again, the ones you are most competent in. You’re creating a business, not a beautiful snowflake.
How do I build this so it can scale?
Int the beginning, it’s best to ignore this. If the biggest problem you have 3 months after launch is that you need to re-architect the product for scale then your in a better place than most.
If you do this then you wont put any unnecessary learning cycles on top of your product design, development and testing lifecycle. Building a new software business isn’t like building software for others; you need to figure out what your making, for whom and why it is important.
So stop worrying about whether your product will be cooler if it’s written in Clojure or would scale better in Rust or would be easier to hire in if it was all JavaScript. Go, write, test and share, it’s the only way forward.
Want to see what I’m up to now? Check out Paperform, it’s like medium editor + form builder = sexy landing forms.