Brief introduction

I’m a solo builder. I built Salute, a cross-platform mobile application focused on structured tracking of workouts, nutrition, and habits — the three core pillars for building a sustainable healthy lifestyle product.

In this post, I want to walk through some of the more significant technical and architectural decisions I made during the last months of development.

Building solo: slow is fast

Working alone changes the nature of execution. You are responsible for both system design and implementation, and every decision compounds quickly.

I tend to work in a highly time-aware way, optimizing small actions and switching contexts efficiently. But when building a full product solo, I had to shift priorities.

I followed a principle I learned from my Brazilian Jiu-Jitsu coach: technique first, then power. In practice, this translated to:

• Prioritizing architecture before implementation
• Spending time on system design and edge cases upfront
• Mapping flows visually (I used Miro and physical sketches). Defining constraints and tech decisions early, but keeping flexibility where needed.
• Although this approach felt slower at the beginning, it significantly reduced rework later and improved overall development speed.

Flutter for cross-platform development

One of the key decisions was using Flutter for cross-platform development.

While I did not perform a deep comparative evaluation with React Native in this project, Flutter proved to be stable and consistent across platforms in practice. The ecosystem was mature enough for all required features, and the community and documentation were reliable and structured.

Claude Code and sub-agent workflows

During the planning phase, I introduced sub-agent workflows as a core part of the development process.

I worked with Claude Code (and evaluated other tools such as Gemini Pro, GPT-based coding tools, FlutterFlow, and Firebase Studio), but found that a structured agent-based workflow provided the most control and reliability.

A key part of this system was building a knowledge layer:

• Collecting official documentation and best practices from Flutter
• Structuring them into modular “skills”
• Maintaining a central instruction file (CLAUDE.md) containing architectural rules and coding standards
• Adding platform-specific guidelines from Android (Material Design) and iOS (Human Interface Guidelines)

This created a reusable, structured context layer for the agents, improving consistency in UI/UX and architecture decisions.

Sub-agent QA system: a major productivity shift

One of the most impactful parts of the system was an agent-based QA pipeline.

As a solo developer, testing becomes a bottleneck. External beta testers help, but feedback cycles are slow and inconsistent. I needed a more deterministic system.

So I built an internal QA pipeline composed of multiple specialized agents:

1. Screeners

Each screener is responsible for a specific part of the application (e.g., onboarding flow). Their tasks include but not limited to:

• UI/UX validation against platform guidelines
• Identifying broken states or missing edge cases
• Detecting unlocalized or inconsistent text
• Verifying interaction behavior
• Responsive and adaptive UI

They operate with direct access to the running app via MCP tools and the Dart SDK environment.

1. Validators

Validators review screener outputs and filter noise:

• Remove false positives
• Split overloaded screener tasks when necessary
• Improve signal-to-noise ratio in reported issues

They do not modify the system, only verify findings.

1. Reviewers

Reviewers consolidate validated findings into structured reports:

• Summarize issues per feature area
• Refine or generate targeted improvement notes
• Update or extend internal “skills” documentation when needed

They are responsible for turning raw findings into actionable engineering work - for the head agent.

1. Orchestrator

The orchestrator manages execution flow:

• Screeners run first
• Validators refine outputs
• Reviewers structure the final reports
• Implementation follows based on prioritized findings

A key aspect of making this system work in practice was carefully managing agent permissions and tool access. Each agent was given a very specific role, with tightly scoped responsibilities and minimal required context. This was important both for maintaining order in the workflow and for controlling token usage across the system. Overloading agents with broad access or unclear responsibilities quickly reduced efficiency and increased noise in the output, so strict separation of concerns and tool-level access control became a core design principle. When optimized - it works very good and saves priceless time.

Technical QA infrastructure

The QA system was built around a direct runtime connection to the Flutter application using the Dart SDK MCP server, which exposes the Dart Tooling Daemon (DTD) and flutter_driver capabilities to agents.

Each screener agent:

• Launches the app in debug mode on an emulator
• Connects to the Dart Tooling Daemon
• Interacts with the live application through MCP tools

This includes:

• UI interaction (taps, input, navigation, scrolling)
• Widget tree inspection
• Runtime log and error monitoring
• Hot reload / hot restart cycles Because agents interact directly with the running app, there is no need for traditional test harness code.

I intentionally avoided integration_test due to both architectural constraints and known build issues (notably release-time dependency stripping of required libraries under R8, which can break plugin registration).

Outcome

This QA architecture significantly reduced manual testing overhead and improved iteration speed during development. For a solo builder, it effectively acted as a scalable internal QA team, without introducing heavy testing infrastructure.