Tech Lead

The Tech Lead runs the Upfyn Dev Team. You describe the app you want in a sentence or two. The Tech Lead turns that idea into a plan, hands each piece to the right builder, checks the work and tells you what changed in plain words.

Think of the Tech Lead as a site foreman. The client shows the drawings, but the foreman decides what gets built first, who does each job and when the work is good enough to hand over. You do not need to know which tools to use, how big the app should be or in what order to build the parts. The Tech Lead makes those calls for you.

Use the Tech Lead for anything bigger than a quick fix. A new app, a new feature or a set of changes that touches many pages is its job. For a small change, Upfyn can send you straight to the one builder who needs to do it.

• Start a new app from a sentence or two, and size it sensibly: a simple page, a prototype, an MVP (a first working version) or a full production app.
• Break the work into tasks and hand each one to the right member, in the right order, so nothing is built before the thing it depends on exists.
• Check every result, including how it looks in light and dark mode and on a phone, before moving on to the next task.
• Keep a running record of the project, so you can pick it up again in a fresh chat without explaining everything twice.
• Explain how your project works, give a status update, review the code or check its dependencies when you ask.
• Work in the Files, Review, Terminal and Browser panels, so you can see the code, the changes and the running app side by side.
• Use GitHub, Linear, Jira, Slack and Gmail once you connect your own accounts. Other apps can be added later in Teams.

The Tech Lead has 21 skills. Each one is a playbook for one kind of job.

start takes your idea, asks one or two questions and sets up the project record before building. For example: "Start a new app for my yoga studio."

build runs the full build from the project record, handing out tasks and checking each result. For example: "Build the whole site we planned."

add-feature adds a feature to an existing app and records where it lives. For example: "Add a waitlist to my booking page."

add-page adds a new page that reuses the app's shared parts. For example: "Add a Contact page."

modify-ui makes quick look changes, such as layouts, colours and spacing. For example: "Make the buttons rounder."

generate writes one piece of code, such as a component or a test, from the team's patterns. For example: "Generate a reusable price card."

connect-data links the app to an outside source such as a spreadsheet or Notion. For example: "Show my product list from a Google Sheet."

fix finds the cause of a bug, applies a targeted fix and checks that it works. For example: "The contact form does not send. Fix it."

refactor tidies code without changing what it does, after showing you a plan. For example: "Tidy up the checkout code."

review checks code quality, with lighter checks for smaller projects. For example: "Review the code before we launch."

deploy plans putting the app online and asks before anything goes live. For example: "How do I put my site online?"

update-deps lists outdated packages and security holes, then updates them carefully. For example: "Check my app for outdated packages."

status gives a quick progress update from the project record. For example: "Where are we with the project?"

explain describes how one part of the project works. For example: "Explain how the login works."

config shows or changes project settings, such as the size of the app. For example: "Show my project settings."

index checks the project record against the real files and rebuilds it if they drift apart. For example: "The project record looks wrong. Rebuild it."

resumeproject picks up an existing project in a fresh chat. For example: "Resume my booking site project."

help shows the Dev Team's members and what each one can do. For example: "What can the Dev Team do?"

project-checks runs guard checks for hardcoded secrets and risky commands. Nothing runs without your approval. For example: "Check my project for passwords typed into the code."

clone-recon maps an existing app's screens, flows and features from public sources and your own account. It learns the features and never copies the original's code. For example: "Map out the screens of this app."

clone-architect plans the stack, database and routes for a clone from that map. For example: "Plan the database for my version."

1. You type: "Build me a booking site for my yoga studio."
2. The Tech Lead sizes the work. A simple page may be enough, or a bigger app with accounts and bookings. It tells you the size in plain words and asks no technical questions.
3. It writes a short plan with the parts in order. The look comes first, then the pages, then any booking data.
4. The Product Designer sets the colours, type and spacing, so the whole site feels like one product.
5. The Frontend Engineer builds the pages on that look. The Backend Engineer adds the booking data only if the plan needs it.
6. The Tech Lead checks each result. It looks at the pages in light and dark mode, and at the phone layout, then sends fixes back to the right member.
7. Before it calls the build done, it confirms the build runs without errors. If the site needs to go online, it asks you first.
8. You get the booking site, a plain summary of what it can do, how to run it, and a project record you can reopen in a fresh chat.