Skip to content
Home » Ideas » Dev Tools: finding the bugs 

Dev Tools: finding the bugs 

    Domain: Dev Tools

    Status Reached: Raised $2M, 10 employees 

    When: Dec 2021-Dec 2022; pivot and then Dec 2022-Dec 2023. Additional ideation for 6 months. 

    Team skill set: Three co-founders, met in 8200

    Thesis/ Idea

    V1:

    We took a problem we had as devs: the need to write tests, which devs hate. The idea was to automate that task using an IDE plugin that allows developers to add unit tests while they write code, not based on AI. There was a lot of hype around dev tools. 

    Most developers use IDEs, Postman and GitHub Copilot. We wanted, like many others, to be the fourth tool. The tool generated tests code in Python based on input, outputs and mocks we intercepted while the user’s software executed on development and in dev/staging environments. The technology hooked Python’s interpreter and was very deep and advanced. 

    V2:

    Developed a plugin that connects to CI/CD and finds bugs. This was an R&D-wide tool, so it brought value to the entire R&D org vs. to a specific end user. Once a user opened a pull request, they received a comment to the pull request indicating what bugs were found. The idea was to find regressions/unwanted changes using dynamic software behavior comparison – before and after changes. We were focused on backend and unit-level testing, which is a less crowded market. The product would create an alert when there was a bug, automatically and without any intervention from the user’s side. Not competing with AI this time. Once installed, all users who pushed code to Git received alerts when needed. In this version, we touched the VP R&D’s KPIs directly (development velocity and bugs that slip into production).

    We came from a code-focused perspective, but in order to sell we focused on developer productivity. We tried to make a connection between velocity of work and finding bugs, which was not easy, but possible. 

    Why the idea(s) didn’t progress

    V1: 

    • Lack of business case: The VP R&D doesn’t really care if there isn’t clear ROI and if you don’t affect their KPIs directly and considerably. 
    • Underestimated AI’s ability to fill the same need. GPT and GitHub Coplit were in their early days back then (ChatGPT was not even released).

    V2: 

    • The product didn’t offer enough value. We identified bugs once every couple of months, so it wasn’t worth the investment from the customer’s side. We realized that even more money wouldn’t allow us to make the product valuable enough because the problem was so technologically deep/complex and we could not find enough bugs using the approach we had taken (dynamic, not AI-dependent).
    • Also, we were working on finding bugs only in Python initially, and we were constantly chasing to support new versions. What wouldl happen with other versions and languages? How much money and effort would be invested? How much value would we be able to provide?

    Research

    Talked with hundreds of developers, team leaders, software architects, VP R&D, QAs (engineers and managers),  and Directors of Engineering. 

    Insights

    • For many first timers, the goal is to raise money, build a company and bring on employees. So you wind up disregarding red flags along the way and focusing on the wrong goals (hint: focus on revenue only. Can your product ACTUALLY generate revenue?).
    • When starting a startup, we tend to think that everything is possible (which is generally true), but we learned that as a founder, choosing to maximize your chances to succeed could be more efficient than making the impossible possible. 
    • Product led growth (PLG) is a common term used by enthusiastic dev-tool startup founders. We learned that it could be used as a marketing strategy, but as its name indicates, it should be a GROWTH approach, which is not suitable for an early-stage startup looking to create revenue early.
    • Your product should be built around your Go-To-Market approach and not vice versa. You can’t build a product and then change your GTM – it won’t work.
    • When you get feedback about your idea, you might change the story to receive less negative feedback. You then find yourself going to meetings with super-sophisticated answers for concerns (which actually convince people) instead of trying to address them. 
    • A lot of founders see a weakness in their product or plan, but feel like they’ve already put in the time, so maybe it’s worth spending more time (insteading of being brave and stopping earlier).
    • The ROI of your product needs to be very clear. Also, the cost of integrating your tool into the org needs to be a consideration.
    • Your product should affect your buyer’s KPIs; if it does not, it’s either not the right buyer or a very bad product.
    • Don’t focus on a dev tool but rather on an R&D tool. The buyer does not care about the individual developer (unless the developers actively ask for it, which is very hard to achieve).
    • Minimize the amount of people involved in the decision process (if you need 10 devs to agree to buy what you’re selling, you have a problem because reachinf consensus with developers is hard).
    • Try to first solve the problem manually to see if your technological solution thesis even works before developing anything – save time.
    • Be brutally honest with yourself, or reality will, after 2 years of effort.
    • Onboarding has to be easy. It’s one of the most critical parts of the product. 
    • Investors and money can’t solve all problems, like issues with your concept. If you find yourself saying “No worries, we will raise money and make it work,” you might have a serious problem in your startup concept, which won’t be solved with a few $M.