Skip to content
Home » Ideas » Dedicated tool for software architects 

Dedicated tool for software architects 

    Domain: Software Architecture Tool 

    Status reached: Partial Validation 

    When: July 2023 for 2-3 months 

    Team Skill set: Business/entrepreneurship and R&D


    Software Architects are super important to an organization – the things they work on impact massive budgets and the company years ahead -but they don’t have a dedicated tool and instead work on excel, google docs, and lucidcharts. 

    The idea was to build a tool that would be a superpower for software architects – a cross between Figma, Grammarly and Google docs, but for software architects. For example, if a software architect is writing a spec doc for a product, the tool would scan the spec and ask how many users it’s for, or how many will be working on it concurrently, and then suggest that a different database be used to accommodate those needs. The architect may accept the suggestion or may say no, and either way it creates value (in decision making or in visibility on why a decision was made, in collaboration and in adherence to company policies). 

    Why the idea didn’t progress

    • I wasn’t interested in spending 7 years on it. This is a very technical world and I am more interested in starting with the business angel. 
    • The founder and CEO should be closer to architecture. I was close to it 5-10 years ago, but have been doing more management in recent years. It should be someone who was a CTO for a long time and has built complex systems. Also at least one member of the team should likely have deep background knowledge of software architecture principles.


    • We did partial tech validation. I’m still not clear what the willingness to pay is.
    • We spoke to VPs and software architects. The VP conversations went well. Less so with architects. They are often tough people, that make big salaries ($500K-$1.5M in the U.S.) and don’t like change. Some of them liked the concept but didn’t want more friction in their UI, even if it was a better tool. 
    • There’s also ego in this world. Architects are used to very minimal oversight and there is sometimes friction between management/VP R&D and architects. 
    • There is also a product question: how do you build a tool so that it’s part of a daily workflow. Architects are very strong so won’t use something if it’s irritating or doesn’t work with their flows. (Grammerly, for example, understood that they need to be an extension). 


    Even though it wasn’t for us, I think there’s a clear need for a tool like this. There are a lot of code co-pilots, but none for architects.