My development workflow: discovery, AI agents, a VPS, and feedback

An account of how I organized a process that runs from the first product question to feedback from the people using the software — and why it lets me keep several fronts open at the same time.

For a long time, my way of building software was fairly simple: an idea would come up, I'd open an agent, hand over the context, and start implementing.

That approach is great for small prototypes. The trouble starts when several projects are moving at once, when there are decisions made weeks ago, bugs that look like code problems but actually start in a requirement, releases to prepare, and people using what you've built.

Today I have something close to eight projects running in parallel, including open-source tools, desktop apps, and games. What made that viable wasn't finding a miracle prompt or picking a single AI model. It was putting together a process that preserves context, distributes execution, and requires validation before anything counts as done.

This is the workflow I use for my personal projects. It isn't a universal model or a corporate playbook. It's a system that evolved through real mistakes, and I keep adjusting it as new tools and new problems show up.

Before going into each stage, here is the full map. Click a stage to see what goes in, what comes out, and where it leads; feedback from the last one loops back into discovery and the backlog.

01The first deliverable is understanding the problem

I don't start a project by opening the editor. I start with discovery.

I mainly use ChatGPT to frame the problem, compare approaches, study constraints, raise hypotheses, and sketch possible paths. When I need to work with additional reference material, I also turn to NotebookLM.

The goal isn't to ask an AI to tell me “which app to build.” It's to reach a reasonably solid understanding of why the project should exist, who it's for, what value it would deliver, and which parts I still don't understand.

At this stage I like turning vague ideas into concrete questions. What's the core problem? What would a useful first version look like? What are the dependencies? What happens on the happy path — and what happens when it fails? Is there something that can be removed instead of built?

Discovery doesn't need to be huge. It needs to be good enough to guide the first decisions.

02I don't validate discovery on my own

After the first pass, I send the material to another agent whose job is to QA the discovery itself.

It isn't there to agree with the document. It's there to challenge it. I want it to look for weak assumptions, forgotten scenarios, inconsistencies, technical risks, and questions nobody has asked yet.

That second look tends to be valuable precisely because the first version of an idea usually carries our own assumptions. It's easy to mistake something that was well explained for something that was actually validated.

The feedback triggers another round of questions. I revisit the proposal, go back to the references when needed, and only then move on to structuring the execution.

Discovery, for me, isn't a document you write once. It's a hypothesis that has to survive hard questions.

03I turn understanding into executable material

With the problem clearer, I organize the project. Depending on the complexity, that means a PRD, scope, backlog, dependencies, roadmap, and acceptance criteria.

This is where I learned an important distinction: a backlog isn't a collection of wishes. Every item needs to exist within a larger intent, and order matters. A technically easy task can be a terrible priority if the foundation it depends on isn't ready yet.

Acceptance criteria, in turn, leave less room for improvisation. “Implement controller navigation” is an intent; spelling out how focus behaves, how it returns, what happens when there's no selectable element, and how to test the result starts to become a verifiable specification.

The roadmap stays adjustable. I want a clear direction, but I don't want planning to stop me from reacting to new findings. That balance between documentation and adaptation made it simpler to work across several projects without reinventing the process every time I switch context.

04The computer I'm using isn't the center of development

After planning, execution moves to T3 Code running from my VPS.

I have a Windows desktop and a MacBook. Both serve as access points to the same remote development environment. The infrastructure stays online continuously, without depending on me keeping one of my personal machines on.

That changed my routine for three reasons. First, I can pick up work from almost any computer. Second, the environment's state stays concentrated in one place. Third, I can leave long tasks running for 15 or 20 hours when they don't need a decision from me at every step.

The VPS also gives me a stable place to run agents, repositories, and automated tests. That doesn't mean every possible test runs there — some apps need specific platforms or devices — but it supports a large part of the flow without tying my routine to a local machine.

05LippStack: the shared practices layer

A central piece of this setup is LippStack, my public repository of skills and mods for development agents.

It doesn't exist just to store reusable prompts. The idea is to make good practices available to agents at the moment a task calls for each one, without dumping every instruction into every context.

Among other components, the repository includes:

• Product skills: discovery, problem statement, PRD, prioritization, roadmap, stories, and planning.
• Engineering skills: root cause investigation, exploratory QA, regression, and delivery preparation.
• Design skills: visual analysis, animation, prototyping, and stress-testing interfaces with extreme data.
• Development mods: progress indicators, context, notifications, and guardrails for destructive actions.

I also like two explicit rules in this base: investigate the root cause before fixing symptoms, and write a regression test for bugs found in QA. LippStack helps make those practices repeatable instead of depending on my memory.

It isn't a magic layer that eliminates decisions. It's a way to standardize how I ask, implement, review, and deliver.

06The platforms behind the day-to-day

Before getting to the agents, it's worth showing the rest of the toolbox. Agents do most of the execution, but the workflow depends on a set of platforms that covers what happens before and after the code: meetings, voice, research, planning, memory, deployment, and recurring tasks.

On the input side, I use Granola to transcribe and summarize the meetings I'm in, and Superwhisper with a local model so I can get things done by talking.

In discovery, NotebookLM handles deeper research, and ChatGPT handles conversation: working through QA problems, or just talking things over to get more ideas. Whatever becomes a decision goes into Notion, where I keep notes, acceptance criteria, and the backlog.

After the code, Dokploy Self Hosted manages deployments across my five VPSs in a more organized way. AI Memory and Obsidian keep the context, and Hermes Agent and OpenMausBot takes care of recurring tasks I need to organize and schedule.

The split between AI Memory and Obsidian has its own logic, which I explain in section 09.

07My orchestrator doesn't have to write everything

With the context prepared, the most distinctive part of the process comes in: orchestration.

I use Opus 5.5 as the main orchestrator. Its job is to understand the request, break it into parts, decide what can be delegated, receive the results, and make the first approval.

The central decision here is not requiring a single agent to be researcher, architect, executor, critic, and QA all at once. That tends to concentrate errors and make a session run too long. I'd rather separate responsibilities.

Choosing the subagent takes into account the nature of the task, the cost of keeping it running, and the depth required.

For general implementation, I usually use Opus 5.5 as the executor for delegated tasks.

When I'm facing an especially complex implementation, I turn to Fable 5.1.

For quick, well-defined tasks, I prefer Gemini 3.8 Flash.

When I have a long or recurring task with lots of requests, a frequent alternative is DeepSeek 4.1 Flash.

For generating images and visual assets, I prefer Codex.

I also use GPT 6.1 Sol, GPT 6 Astra, and Sonnet 5.5 for analysis, development, and support work, depending on the context.

These are the names I use to describe my current set of agents. This isn't a universal model ranking: the best route can change with the task and with the results I observe.

08The loop only closes after independent review

When a subagent finishes a task, the result goes back to Opus 5.5. It checks the deliverable, compares the result with the goal, and makes a first assessment.

Then another instance of Fable 5.1 steps in as QA, separate from the execution being reviewed. This agent looks for problems, compares the result against the defined criteria, and signals whether the deliverable is approved or needs changes.

The cycle can go back to implementation as many times as needed. Instead of assuming that “the agent finished” means “the feature is ready,” I try to create clear checkpoints.

Human review is still relevant, especially for decisions about scope, perceived quality, and the product's final behavior.

Orchestration shouldn't turn a lack of supervision into a synonym for autonomy.

09Memory can't depend on the current session

A flow with several agents and projects has to answer a basic question: how do I recover the right context without rebuilding it from scratch?

That's where my second brain and my continuity base come in: Akita's AI Memory and Obsidian.

I use these tools as part of the work's memory — decisions, history, stage of development, open items, and context that needs to survive switching sessions. The goal is for every project to have a recoverable trajectory, instead of depending on me remembering everything the next time I open an agent.

Each one has a role. AI Memory organizes all of my project memory, no matter where I'm working from. Obsidian is the second brain that supports projects and tasks from other contexts: if I simply had a conversation about something, AI Memory won't cover it, but Obsidian will.

Git and technical documentation are still important in this process. Conversational memory helps recover the why; the repository, tests, and documents help confirm what actually exists.

That's how I try to reduce the biggest cost of running many projects: not the time spent coding, but the time spent figuring out again where I left off.

10Postaí: a release is also a conversation

Building the app is only part of the work. If nobody tries it, points out difficulties, or reacts to the changes, the product's evolution stays stuck in my own point of view.

To reduce that friction, I built Postaí, an automated publishing tool for X, Reddit, and LinkedIn.

It connects to the context kept in AI Memory and Obsidian. That way, an update to a project like Console Mode can become a post based on what actually changed, without me having to rebuild the whole release story every time I publish.

The goal isn't just to produce posts. It's to make it easier for news to reach the right people and to bring feedback back to the product. A recurring criticism, suggestion, or question can become a new discovery question, a backlog item, or a change in priority.

11An end-to-end example

Imagine I want to add a new feature to Console Mode. This is an illustrative example of the path it would take.

1. Discovery: I investigate the need in ChatGPT, consult references, and identify the main scenarios.

2. Discovery QA: another agent questions the gaps and forces decisions I haven't made yet.

3. Specification: I document scope, dependencies, backlog, and observable acceptance criteria using LippStack's practices base.

4. Remote execution: I open the T3 Code environment on the VPS and hand the request to Opus 5.5 for decomposition and delegation.

5. Specialized implementation: one or more subagents handle the parts that fit each one's strengths.

6. Review and QA: the result goes back to the orchestrator and then through independent review, with corrections when needed.

7. Continuity: I record the state and context so the next session starts from the right point.

8. Communication and feedback: Postaí uses that context to support the announcement; whatever comes back from the community feeds the next iteration.

I don't need to run every stage with the same weight for every small tweak. The value is in having a predictable process that scales with the complexity of the request.

12What this system solves — and what it doesn't

The biggest advantage isn't a promise of infinite speed. It's reducing the friction between thinking, delegating, validating, and picking things back up.

That's exactly why I separate the phases. I want the hard questions to surface early, deliverables to pass through more than one set of eyes, and every important decision to be traceable back to where it came from.

The benefit of working on several projects isn't pretending they're all the same. It's making sure each project has a legible state, an explicit direction, and a repeatable way to move forward.