Designing a developer tool from the ground up.
As Codiga’s founding product designer, I shaped the product across web, IDE, and desktop experiences: turning static analysis, code quality, and reusable code into workflows developers could understand and use where they already worked.
Code quality only works when it fits the way developers work.
Static analysis can expose a huge amount of technical information, but developers do not want another destination to monitor. Codiga needed to surface the right signal where work was already happening: while writing code, reviewing a pull request, or understanding a project.
As Code Inspector became Codiga, my role was to turn a growing set of web, IDE, and repository workflows into one coherent product while it was already serving more than 10,000 developers and 600 organizations.
Designing while the product and company were growing.
Codiga grew from more than 10,000 developers during the redesign to more than 20,000 users later that year.
Shape the product, then stay close to how it shipped.
As founding product designer, I worked across product direction, static-analysis and review workflows, IDE experiences, the interface system, and implementation. The job was less about owning isolated screens and more about keeping the product coherent as new surfaces were added.
From finding to action, without leaving the code.
A pull request already contains the file, changed lines, and discussion. Codiga adds the finding directly to that context so a reviewer can understand what happened, why it matters, and what to do next without reconstructing the problem elsewhere.
One finding. Each platform’s review language.
The same finding adapts to each host instead of forcing a separate Codiga interaction. GitLab places it in the review discussion; Bitbucket adds severity and category context. The product language stays consistent while the interaction respects each platform’s review conventions.
Make the next step visible.
The suggestion module completes the flow by pairing the warning with a proposed remediation and explicit Apply Fix or Dismiss actions. Detection, explanation, and action stay together.
Define and organize analysis before it reaches the developer.
The finding is the end of a larger system. Custom Rules brings configuration, rule logic, and test cases into one workspace; Ruleset Sharing makes that configuration reusable across a group.
Move between the overview and the detail.
Project views move from a single finding to codebase health: category and severity distributions, technical debt, analysis history, and paths back into individual reviews. The scores visible in these recordings are project data, not measures of design impact.
Build the system while building the product.
Codiga was a small, fast-moving team, so design could not stop at polished screens. I built reusable interface patterns and worked close to implementation to keep web, IDE, and repository experiences aligned as the product expanded.
That proximity to the shipped product made the system practical: patterns were refined against real constraints, reused across surfaces, and adjusted without turning every new workflow into a separate design language.
Codiga grew from a web-based code-review product into a broader developer platform spanning static analysis, automated reviews, security analysis, custom rules, and reusable code across IDEs and CI/CD. In 2022 the company was acquired by Datadog, where the static-analysis technology continued inside Datadog Code Analysis.