How We Build at GoVisually: The May 2025 Edition

GoVisually is built by a very small team. We always optimize for speed and deliverability, and of course, usefulness to our customers. By keeping the team small, we try to use the best available tools and resources to help us move fast and stay focused on what matters most. Our process keeps evolving as new tools come along, so here's a look at how we build today.

Starting with an Idea

Most new features for GoVisually start as notes on our product roadmap or from discussions during Slack chats and team calls. Anyone on the team can contribute ideas or highlight customer pain points that need addressing.

These initial concepts then go through AI-assisted research and v0 prototyping to explore potential solutions. Once we've validated the approach, we formalize everything into GitHub issues to track implementation. This combination of structured planning and flexible exploration lets us stay organized without losing agility.

But we don't strictly adhere to this. Sometimes we build even before we plan.

Designing and Prototyping with v0

We don't really design in Figma anymore. Instead, we use V0 to quickly prototype the feature or functionality. We have already setup a project on V0 with our Figma files, our shadcn/ui theme config, and even our help section. With all this context, v0 helps us design and prototype new features for GoVisually, often without much help from developers.

Once the prototype looks good, a developer can import the code into Cursor and start integrating it into the app. Sometimes, we use screenshots from v0 as a reference, especially since we're still on an older version of shadcn components.

Getting Ready to Build

When a developer picks up an issue, they use Cursor to pull in everything they need. On cursor we keep all projects on the same workspace, so that the same Chat can have access to all the code; frontend, backend, and testing; together with the docs. Most the planning is done using a model with larger context window and we update the issues on github with the plan.

We also start by creating a branch for the feature, and adding Markdown files with the plan, the research, and the notes from the conversation with the AI. This essentially will become part of the project wiki.

Prototyping, Pull Requests, and PR Apps

When we're ready to implement a feature, we create a GitHub pull request for each issue. Our system automatically deploys these PRs to dedicated preview environments, giving us working versions of every feature in development. This lets us interact with and test each change in isolation before it impacts the main product.

This is when Code Rabbit comes in. It has surprised us on every PR. Code Rabbit has flagged issues ranging from simple naming conventions to complex problems very specific to our codebase. And as we give more context and even chat with it, it learns and improves. And its Nitpicking suggestions always pushes the code quality higher.

Reviewing code with Cursor

We've found Cursor to be a powerful tool for our code review process. With Github MCP, Cursor can access PRs and retrieve context from Github. This along with local code access of the branch gives it complete context of the changes to review.

This makes code review really easy. We can essentially discuss the code with Cursor and delegate the more repetitive aspects of review, like checking for consistent patterns or verifying edge cases. Code review is not fun, and the more picky you are the more your review is dreaded by other devs. At least having an AI assistant makes the review and the feedback process a bit more bearable.

When Code Rabbit flags potential issues, we discuss them with Cursor to better understand the suggestions and decide on the best approach.

Testing and Feedback

Our testing environments are completely sandboxed, giving us the freedom to thoroughly test every aspect of new features in isolation. This isolation allows our entire team to interact with the feature; developers, designers, and product managers can all evaluate it in a realistic setting. This also allows us to run our full cypress e2e test suite against the PR app.

As feedback comes in from across the team, we continuously update the GitHub issue with new insights and make iterative improvements to the implementation.

Release Process

We follow a custom Gitflow pipeline for our continuous integration process. For each release, we create a dedicated PR that merges the changes into our main branch.

Throughout this process, those Markdown files we created during the planning phase prove invaluable; they become part of our AI knowledge base and provide context when reviewing code.

Looking Ahead

AI models are becoming better and better at handling complex coding problems. I believe they were already pretty good and were mostly lacking in context. Now with newer models (Claude 4 Sonnet releasing yesterday) and larger context size, the way we use AI in building applications and solutions will keep changing.

For teams like GoVisually, who are focused on solving consumer problems, we are less concerned about AI Benchmarks than how they can help us deliver value to our customers.