Backend Engineer

The Backend Engineer builds the parts of your app that people never see. That includes the database where your data lives, the sign-in, the payments, the emails and the logic that decides what happens when someone presses a button. Bring it in when your app needs to remember things, sign people in or talk to another service.

Think of the Backend Engineer as the kitchen behind a restaurant. Guests only see the dining room, with the menu and the plates. The kitchen takes the order, checks the stock, cooks the food and sends it back out. If the kitchen is well run, the guest never notices it. The Backend Engineer makes sure the kitchen works, and that every order that goes out is right.

The same idea holds for your data. A library's storeroom keeps every book in a known place, with an index card that says where it is. The Backend Engineer builds that index for your app, so every customer, order and product can be found, changed and checked quickly, without a search through the shelves.

The problem this member removes is the hidden work that breaks apps. Data gets lost, sign-in fails, errors show code nobody can read, and a list of a thousand items loads all at once and freezes the page. The Backend Engineer plans for bad input, slow networks and half-finished writes from the start, so these problems are designed out instead of patched later.

• Build the routes (the doors the screens knock on) that send data to and from the screens. Each route checks who is asking before it returns anything private.
• Design the database, the store where your data sits, and plan any change to its structure as a migration that can be rolled back if something goes wrong.
• Add sign-in, file uploads, email and live updates, so people can log in, share files and see changes as they happen. Passwords and keys are read from the environment, never written into the code.
• Set up payments in a safe test mode first, so no real money moves until you are ready.
• Connect your app to outside data such as Supabase, Firebase, Airtable, Google Sheets, Notion or a plain CSV file.
• Return clear messages people can act on, for example "An account with this email already exists", and split long lists into pages from the start.
• Track down server bugs from logs and failing tests, and fix the real cause rather than the symptom.
• Write down the exact shape of each route, so the Frontend Engineer builds against the real thing and never guesses.

The Backend Engineer has three skills. Each one is a playbook for a kind of back-end job.

generate writes one back-end piece at a time, such as an API endpoint, a database model or a test, using the team's proven patterns. It writes the tests alongside the code, so the piece can be checked at once. For example: "Generate a products API with list and create."

connect-data links your app to an outside source and wires the data into your screens. It sets up the connection and the safe proxy route that keeps your keys out of the browser. For example: "Pull my product list from a Google Sheet into the shop."

clone-backend builds the back end of a clone: sign-in, database rules, payments, email, background jobs and links to outside services through their official APIs. It uses your own keys and ends with a security checklist. For example: "Add login to the clone."

1. You type: "Let customers create an account and save their orders."
2. The Backend Engineer reads what the screens need. A sign-up form needs to send an email and a password. An order list needs to show each customer's own orders and nobody else's.
3. It plans the data: customers, accounts and orders. Before it changes the shape of the database, it stops and asks you for a yes.
4. It writes the sign-up and sign-in routes with checks on every field. If an email is already in use, the reply says so in plain words, not as a raw database error.
5. It writes the order routes with the right status codes. A new order returns "created", a bad field returns a clear field error, and a request from someone who is not signed in is refused.
6. It tests each route with a real request or a test, and shows you the results. It does not say the work is done until the checks pass.
7. It records each route's shape in the project record, so the Frontend Engineer builds the sign-up form and the order list against the real data.
8. You get working sign-up and saved orders, a short list of the routes, and a note on what to check before it goes live. It asks before it deletes records, changes the database's structure, touches live data or pushes anything live. Database changes are planned so they can be rolled back.

What you get at the end is a back end you can test yourself. Sign up with a new account, place an order, and see it appear in the list. Every route has been checked, its shape is recorded for the Frontend Engineer, and nothing has gone live without your yes. You also get a list of what changed and any decision still waiting for you.

Call it whenever your app needs to remember something, check something or talk to something else. Accounts and sign-in. Orders that must still be there tomorrow. A payment that has to be recorded once and only once. A nightly job that sends reminders. A connection to a service you already use, such as a payment provider or a calendar. If the job happens behind the screen rather than on it, this is the member for it.

You do not need to describe tables or routes. Say what the user should be able to do, and the Backend Engineer works out what has to be stored, who is allowed to see it and which steps must never run twice. It writes down the shape of every route it builds, so the Frontend Engineer can build the screen without guessing, and it writes tests beside the code so a later change cannot quietly break sign-in or checkout. Keys and passwords stay in your environment, never in the code and never in the chat.