Product Development · Software development

Do you need technological review for project at idea stage?

Ofer Elrom

October 23rd, 2015

I am working on a service to ease and automate the process of turning ideas into software products.

A first stage in this service is reviewing technology that is related to an idea and creating initial software architecture.

Do you think this is a required feature on its own?

Would it benefit you to have an experienced top level software architect review technologies around your idea and supply initial software architecture?

Joe Emison Chief Information Officer at Xceligent

October 24th, 2015

Most startups fail because there is no market need for what they build. Once you reach product-market fit, you will have time and resources to rearchitect and refactor what needs to be redone. 

Struggling with growing problems is a much better problem to have than having an amazingly scalable architecture and no product-market fit. 

You will also find that the "best practices" scalable architecture today is different than what it will be in 18 months, when you need it. You will have over engineered and delayed your launch to have a suboptimal architecture when you need to scale. 

The principles of Lean Startup are correct: do everything to get to PMF and nothing else. 

Jake Carlson Software Development Manager at Oracle

October 24th, 2015

Looks like I'm going to be the only dissenter here. ;)

Startups need good technical cofounders. It's true that architectural decisions will be biased toward the technologies familiar to him/her, but that's not always a bad thing so long as the technologies chosen are viable tools for the job. After all, he/she will be in the trenches doing the work, not some third party tech advising service. 

Having a third party make those decisions up front has no better chance of not being biased toward the sensibilities of the chooser, and has a much higher chance of pigeon-holing the startup with tech that doesn't match the skill set of an otherwise ideal future technical cofounder, or the skill sets of available technical talent in general. 

If I found a perfect fit as technical cofounder but the startup already had a third party recommendation for a tech stack I either don't have experience with or just plain disagree with, what then? Either they pass on me for that reason (which is a shame and a missed opportunity for both parties), or I come in and reevaluate / change the stack (which means they wasted time and money on the third party recommendation). Or, I suck it up and learn the new stack, wasting time and money in the process, and likely making me bitter about those fundamental technology decisions made without me. 

Startups that involve heavy technical components need senior technical leadership, and they need it early. That leadership should be making the decisions, not a third party.

Tim Scott

October 24th, 2015

IMO, this is a terrible idea. 

So I've got my architecture, now what? Skype the lead Ukranian dev and ask if they can use [shiny new hotness] instead of Rails? The answer will of course be, yes. And they will build it, for maybe 30% more. In addition to all the corners they usually cut because I'm uber cost conscious, they'll cut a bunch more because they're just learning the idioms and magical parts of this newer "future proof" stack.

Technical debt and scaling headaches are wonderful problems that most startups never ever come close to having. The fact that Twitter dumped Rails after it's jillionth user is utterly meaningless to a seed stage startup. Indeed studies have shown that worrying about future problems like robust architecture early on can positively prevent you from ever climbing out of the the crib.

If I'm a non-technical founder one assumption I must make is that my product idea is mostly wrong. That means our product must change frequently, drastically and quickly. It means I need a full time technical leader who knows something about how product-market fit is found. I need someone who loves me enough (has a big stake in the upside of the company and not so much resume building or fees) deciding which corners to cut and which to never cut. A less smart or less aligned implementer will yield you a bigger pile of technical debt even if they start with a "prefect" architecture. IMO, architecture emerges from a long series of smart decisions by smart people with the right incentives. It's a mistake to see it as a discreet task.

Another point is that, the "future proof" technology isn't. Our craft always goes down blind allies and follows cargo cults. For example, it turns out many problems thought to be no-SQL-shaped turn out to be more relational-shaped. How many single-page apps today are horribly over-engineered? It's devilishly hard to know which path to start down on day one, so you're best to expect to switch paths probably more than once.

Dan Dascalescu Developer Advocate at Google

October 24th, 2015

The initial architecture and technology choice create a path dependence in a product that becomes more and more expensive to change as the time goes by.

I've seen many project suffer from very high technical debt because of poorly thought out initial choice. For example, the lead of one project had picked a certain language for the backend of a web app simply because he was comfortable with it. Later as he tried to hire new team members, he found out that experts in that language were harder and harder to find, as the technology front had moved forward. Libraries were no longer being maintained etc.

This was the situation with Perl (which I had been a huge fan of) and these days we see more and more projects from from Rails or .NET or Java to JavaScript-everywhere platforms like Meteor. (JavaScript is eating the world.)

Technology debt can bite back very hard, and it's definitely worth the investment to make a solid initial technology choice, that's as "future-proof" as as anything can be future-proof in the software world.

Ofer Elrom

October 24th, 2015

Thank you all for replying. This is very helpful.

I would like to add that technological review can also be focused on what is the quickest and least expensive route to create the MVP you need.

This will usually involve prioritizing features by cost benefit ratio and finding existing technologies you can utilize instead of building from scratch.

Rob G

October 24th, 2015

At the idea stage lf anything a simple sanity check will suffice. A tech review and  certainly an architecture plan though nice is not something I would spend much time on and certainly not money on unless what I was planning to build was outside the lines.  Just keep me between the guard rails. Focus more on"don'ts" than "dos". 

Joe Emison Chief Information Officer at Xceligent

October 24th, 2015

Ofer's recent comment above is spot-on, but I wouldn't call that a technical review. But a process whereby you figure out the best way to get real product to customers and can test real adoption ASAP is excellent. And I would even delay hiring a CTO (who will likely come with a preferred stack that probably isn't the fastest way to get to PMF) until after you have customers, even if they're using a product held together with duct tape. 

Sam Colwill Owner/Chairman at BathroomsByDesign Retail Ltd and Owner/CEO at KADware Ltd

October 24th, 2015

Sounds like a very appropriate service for any business looking to explore possible solutions for their ideas or challenges in a lot of cases.

The service needs of a small business will be significantly different to that of a large corporate, as well the level of complexity of the solution they seek, such as a basic app for narrow functionality through to complexed ERP systems. Perhaps this poses a slight marketing challenge for the service itself.

In either cases it will always be valuable for a software architect to hold the hand of the proprietor if they can ultimately look to provide a solid plan and extensive brief (most important part) for the best solution without any ulterior motives. Sadly this isn't the case with many software development agencies who will stick to known technologies and always have a conflict between maximising their own profits and providing a satisfactory level of value to their client.

Good luck, and if it's something you pursue please get in touch.

Braydon Johnson-McCormick Proven CEO, co-founder and practical business strategist for real-world results

October 24th, 2015

Hi Joe - I would echo Joe's comment.  For a startup, the most important thing is finding out if there is a market that actually cares about your software.  Once you have some proof points of interest, then the architecture is super critical, but if you delay getting your product off the ground by focusing on architecture first, you'll have spent a bunch of money/time on nothing. 

From a process standpoint I would see it like:

1. MVP/Proof of Concept - in whatever form it needs to be, (but don't be dumb about the architecture/platform of course - but beyond "don't be dumb", don't go much farther in definition, as long as it functions correctly)
2. Demonstrated market interest
3. Build to scale. 


October 24th, 2015

Hi Ofer, At first glance I do believe it's a good idea. I have a couple of ideas I'm tinkering with and both need technology support. I'm a bit busy this week, but would be happy to discuss with you further next week. Warm Regards, Shaheeda Abdul Kader +971-50-7942895 @saq3