Co-founder & CPO
Aikido Security
Aikido: Revolutionizing code and cloud security for early stage and rapid growth companies. With Aikido developers can get a nearly instant deduplicated, noise free overview of all their code & cloud security issues. Aikido shows dev teams which vulnerabilities are exploitable, autofixes many of them and gives human written TLDRs so they can easily fix the rest.
As the product & design co-founder behind Aikido, I wore many hats – from diving into the nitty-gritty of market research to crafting every pixel on our product screens. I brought the big picture to life by plotting our course, digging into market trends, and ensuring the UX was top notch. Check out the breakdown below to see how this startup whirlwind turned into Aikido's awesome journey.
Process & Practices
I find that with my work, almost more impactful to the success or a company than actual feature work is how the work gets done. Ensuring that a company starts with sustainable, flexible practices that speed delivery up instead of slowing it done if the cornerstone to that success and I detailed a few things below.
From a research point of view, Aikido’s journey began with a dive into market research, engaging directly with potential customers to understand their needs and aspirations. Through quite a lot of conversations with technical founders, developers and development team leaders we unveiled insights that confirmed our market fit and expanded our knowledge on their challenges. I translated these findings into a set of clear value propositions. By effectively laying out our data-driven and user-centered vision, we were able secure investment and clearly lay out our product direction.
Building on the insights gained from market research, I continued to drive product strategy through ongoing conversations with customers, leads, and users within our product-led funnel. Working in agile sprints, we prioritized features and infrastructure based on real user needs balanced with more long-tailed innovation, always maintaining a flexible yet goal-oriented approach. A three-month north star guided our path while the short term was flexible and adapted to user needs, this ensured adaptability in the dynamic startup environment.
Something that is important to me in all positions, but even more important at a fast moving startup is that we keep a repository of information, so nothing is lost between team members and we aren’t making gut reaction decisions based on the last call we had, but are able to zoom out while working on necessary features. I built an automated system to import calls, surveys, intercom chats, social comments etc; then to tag those with important topics and we reviewed our insights and learnings each week together to foster a culture of sharing and curiosity vs feature demands and exclusivity. We then collaborated directly with customers who had previously mentioned a feature or use case in the planning of these features, aligning our development efforts with their goals and ensuring a customer-centric approach to innovation.
With all companies, but especially startups, it’s important to be able to move quickly and experiment often, and creating a design system that is mirrored in a component system within the code itself is paramount to that. With a design system that is deeply maintainable and comprehensive; there is very little UI guesswork for designers or developers. This reduces the time to completion for a feature dramatically. It also means it was possible to go through a more mature rebrand within a few months of launch with no major dev time lost.
This design system was a focus of mine from the start, building it up as we designed necessary features. Everything from modals, tables and our entire screen structure was built with interchangeable and deeply nested blocks. I have so much to say on this topic, but will leave it for another day.
Addressing User & Market Needs
As far as the actual feature work, it would be impossible to detail each user problem or case study we solved for in the time we were building and growing the company but I'll break down a few below.
When we just beginning to talk about Aikido, discussing what it would be, it was so clear to me that the market had a huge gap in DevTools in general for early stage companies, scale ups, and even side projects that turn into something great. I had been working within DevOps for many years and almost all of them go straight for enterprise companies with extremely complex needs and it left everyone else either trying to stick solutions together with duct tape, or worse, burying their heads in the sand and not addressing security at all. This makes the entire digital world less safe for everyone. I was on a mission to help. We addressed this in a number of ways.
Pricing: We have a free plan, allowing early projects to grow into something bigger with security at it's core. We also have starter and pro plans that start signiiiiificantly lower than anyone in market. We did this by not reinventing the wheel. We built Aikido's scanners on top of industry standard, open source products, and built our features on top. We lose 0 quality in this way, could build much faster, and keep pricing lower.
Workspaces: Users sign up and use Aikido with their Github (or almost any version control account) and Aikido has the ability to switch between all the companies and projects a user has access to simply, in the same UI. This allows developers to secure their main company, their open source projects and all side projects easily, for free. As those projects grow, Aikido can grow with them, into another plan.
Product-led: In order to try out the product users simply log in to their GitHub and can try it our on a single repo or test repos easily. They can upgrade from there within seconds without having to transition from demos or ever talk to sales. This kept our sales motion lean as well as those costs.
This was one of the problems that drove us to create Aikido in the first place. We were solving a problem that so annoyed us about existing solutions that we needed to create a whole new company. We tackled this problem in a few ways: All in one scanning, deduplication, auto-ignoring, and autofixing.
All-in-one Scanning: We built our detection engine on top of multiple, industry standard open source scanners or vulnerability detection tools (no need to reinvent the wheel there), but while these have been separate and often run in terminals with results that are very overwhelming, we combined them all in Aikido's simple UI.
Deduplication: We took the results and deduplicated them from companies various repos, environments and clouds into single line items. This took the results from these scans from overwhelming and impossible to parse, down to management and quick to triage and autofix.
Auto-ignoring: We built a traceability engine and a series of criteria and rules that sent some 'vulnerability' straight to ignored. Aikido could detect if this vulnerability was actually a vulnerability or a simple autoalert from a package where the vulnerability could never be exploited. This saved an impressive 15,000 developer hours across our early customers.
Autofixing: With Autofix features, you could simply push a button and automatically push simple fixes like formatting issues or package updates to your repos. We eventually introduced a completely automated improvement to this feature as well.
Since we were on a mission to serve the underserved market of early and rapid growth companies we needed to take into concern that these companies were almost always too early to hire a security developer or specialist. Aikido is meant to fill the hole that has yet to be filled by these engineers and support developers in their goals to create more secure products. Some of the ways we did this is by creating human readable TL;DRs, easily understood severity scores, step by step guide to fixing the vulnerabilities that came up for our users and easily understood traceability analysis.
Ultimately, every single extra task a developer does takes them out of the process of creating impact on the bottom line of their own companies. We knew this and at every opportunity we try to make Aikido invisible. If a developer never had to see our UI or complete actions in our tool, that means it's working optimally. We addressed these needs in a number of ways.
Autopatching: We created a flow where Aikido would collect all the vulnerabilities that could be fixed without major changes and with a single button press Aikido could open PRs across all of them, across all of your repos, in all of your environments to fix them all. They would of course, be reviewed by a developer before merging. Almost all vulnerabilities could be solved this way, saving an untold number of developer hours.
CI integrations: Aikido integrates with a companies CI in order to block merging and tell developers exactly what vulnerability was introduced and how to fix it before pushing again. This would all be seen in their normal version control view and didn't direct to Aikido's UI.
Integrated workflow: Aikido integrated into task management products like JIRA or Linear, in order to make triage simple and quick and keeping triage and planning within only one tool.
Slack/Email notifications: Aikido pushed critical vulnerability notifications as well as weekly digests to slack or email, allowing users to ignore Aikido until needed, and even allowing autopatching from those notifications.
In order for Aikido to be the most helpful, it needed to be proactive instead of reactive. We couldnt just tell people that there were vulnerabilities after they were exposed, we needed to keep mistakes from happening in the first place. So we created branch scanning. Every time code was pushed to a companies version control, we scanned the branch for issues that were solved or introduced, and suggested ways to improve code, improve security or prevent a vulnerability from being introduced.
As new laws and regulations are introduced, helping to protect us all, there are new requirements for business' that need to be addressed. Aikido needed to be able to address these needs, in order to be the defacto solution for our market. Those included: integrating with SOCII and security providers like Vanta, SBOM reporting for security regulations and due diligence process', Audit reports showing all the changes made and vulnerabilities solved or introduced throughout a companies history using Aikido. Deep reporting into common security concerns that appear in SOCII and other security compliance process'. etc.
Conclusion
Aikido's journey is marked by innovation, strategic decision-making, and a commitment to user-centric design. As the co-founder and Chief Product Officer, I take pride in steering the product towards its goals through effective leadership and a focus on continuous improvement. While this case study provides a snapshot, the journey at Aikido continues, shaping the future of code and cloud security.
Framer 2023
Amsterdam