Tools, skills, and the product underneath

Understand what you build with.

My first MVPs came together with Lovable, Cursor, and Windsurf. Today I use Claude Code and ChatGPT Astra with skills. Here is how those choices fit into a practical building workflow—and how to choose the technology your product runs on.

Founder's tool journey · Official documentation checked October 2, 2026Our editorial approach ↗

The tools evolve with the work.

I used Lovable, Cursor, and Windsurf to build my early MVPs: the first versions of products that could be tried by real people. That starting point is part of the story behind Pretectal's projects.

Lovable turns natural-language instructions into editable web applications. Cursor's Agent works with files and commands inside a code editor. Windsurf was another part of my early building setup. These are different ways to work on a product; the generated application still has its own code and architecture.

My current setup: Claude Code, ChatGPT Astra, and skills.

I have moved entirely to Claude Code and ChatGPT Astra with skills. That is my current tool choice, rather than a rule that every beginner needs to follow. The useful habit to carry between tools is to make the task, constraints, and expected result clear.

Claude Code

Claude Code can inspect a codebase, edit files, and run commands. A practical first task is one contained change in a preview: provide the product brief, identify the behavior to improve, and ask for the changes and checks to be explained.

Claude Code overview ↗ (opens in a new tab)

ChatGPT Astra with skills

ChatGPT Astra is the name I use for the other part of my current setup. The repeatable part to learn here is the workflow around it: clear inputs, reusable task instructions, examples of a good result, and explicit checks. Choose from the models and tools available in your own workspace.

OpenAI's guide to skills ↗ (opens in a new tab)

A useful first request: “Read this project and explain how one user task works. Propose the smallest change that would improve it, then list how we will check the result before editing.”

Turn a repeated process into a skill.

A skill packages instructions and supporting material for a specific task. It can carry a template, references, examples, or helper scripts. Claude Code and ChatGPT both document ways to reuse these workflows; their setup and invocation details depend on the product.

Start with a process you already understand. A small “review this feature” skill could ask for the intended behavior, inspect the change, run the relevant checks, and produce a handoff with unresolved issues. Keep it focused enough that you can tell whether following it helped.

  • When to use it: the task and boundaries.
  • What it needs: inputs, project context, and references.
  • What it produces: an example or template for the result.
  • How to check it: observable completion criteria and a review step.

Test the skill on a real example and revise it when it misses something. Reusable instructions make a process easier to repeat; the result still needs to be checked.

Know what runs your product

Vite, Next.js, and your backend do different jobs.

The AI tool helps you build. Your product's stack is the technology that runs the result. Vite is a frontend build tool; Next.js is a React framework with server capabilities. A backend handles work such as storing shared data, checking access, and running server logic.

Different layers of a web product
LayerWhat it providesWhat you still decide
ViteA development server and a build process for frontend code. It works with UI libraries such as React.Your application structure, routing, and any backend services. Vite itself does not supply a database or user account system.
Next.jsA React application framework with routing, rendering options, and server endpoints when deployed with a suitable runtime.Data storage, authentication, permissions, hosting, and any separate services. Server features require more than a static export.
BackendServer logic and services for shared data, identity, access, and integrations.Which parts you need, where they run, and who can read or change data.

Vite-based applications can call APIs and work with backend services. Next.js can provide an API layer and connect to those services too. Choosing either one does not automatically solve your data model, user permissions, or maintenance needs.

Follow one piece of data.

Imagine an onboarding checklist. The frontend shows a task and its completion button. If progress is shared across devices, a backend identifies the user, checks permission, and saves the change in a database. Hosting is where the application and its services run. This example could be implemented with either frontend approach.

MDN's introduction to the server side ↗ (opens in a new tab)

Which would I choose for a first project?

For a focused tool that mainly runs in the browser, React with Vite can be a straightforward starting point. For a React product that benefits from integrated page routing, server rendering, and server endpoints, consider Next.js. These are starting recommendations: the existing team stack and the task should guide the decision.

Keep sample data in the prototype until shared storage is needed. When it is, make an explicit backend decision about storage, accounts, permissions, and recovery. A framework name alone is not that decision.

A first setup you can explain.

Choose one building tool, one small task, and a preview you can test. Use Claude Code if you want to begin with the coding tool in my current setup. A visual builder such as Lovable can also be a starting point if seeing and changing a prototype is the most approachable way for you to learn.

  • Write the user, problem, and three acceptance checks in a brief.
  • Ask what runs in the browser, what runs on a server, and where data lives.
  • Keep recoverable versions and try each change before adding more.
  • Turn a process into a skill after you have an example worth repeating.
  • Watch someone use the result and record what needs to improve.

Check the provider's current plan, data controls, and export options before committing your team to a tool. The practical test is whether you can build, inspect, improve, and maintain something useful with it.