Cofounder Docs
Cofounder Docs

Cofounder Docs

Engineer Agent

Use the Engineer for websites, internal workflows, technical growth work, and handoffs to the team or coding agent building your core product.

What The Engineer Is For

The Engineer owns technical work around your product, not the core product itself.

Use it for:

  • landing pages, marketing websites, waitlists, and launch surfaces
  • internal tools and workflows that help the company operate
  • code-generated campaign assets and interactive marketing experiences
  • analytics and growth instrumentation
  • technical SEO and marketing-site performance work
  • repository investigation, debugging, tests, previews, and pull requests for those surfaces
  • implementation briefs and handoff prompts for your product engineering workflow

For campaign strategy, naming, content, or creative assets, use the Marketing Agent. For brand systems, decks, email templates, or UI kits, use the Design Agent. For ICP, outbound, customer development, or pipeline work, use the Sales Agent.

What The Engineer Does Not Own

Build your main SaaS product, mobile app, or customer application in your own codebase with your preferred coding agent, IDE, or engineering team.

The Engineer is not intended to take ownership of:

  • the core product build or a rebuild of an existing product
  • the product database, authentication system, or hosting stack
  • an open-ended product feature backlog
  • replacing the engineering workflow you already use

Connecting a product repository gives Cofounder useful context. It does not change this boundary.

When a task belongs in the core product, ask the Engineer to define the expected behavior, constraints, acceptance criteria, and relevant company context. You can then give that brief to the person or coding agent working in the product repository.

How To Start

Open Canvas, choose Engineer, and describe the business outcome, affected surface, constraints, and review you want.

Strong requests include:

  • Build a landing page for this product, connect the waitlist form, and open a PR with a preview.
  • Create an internal customer-feedback triage tool from this workflow.
  • Add analytics to the marketing site so we can measure signup conversion.
  • Fix the mobile layout on the pricing page and verify it in a browser.
  • Turn this approved product requirement into an implementation brief for the coding agent working in our product repo.

If your request mixes product and company work, state the boundary directly:

Do not change the core product. Build the launch page and analytics here,
then prepare a handoff prompt for the in-product changes my coding agent needs
to make.

Working With Your Existing Product

Product context helps every department do better work. Cofounder can use connected repositories, issue trackers, analytics, customer feedback, and company documents to understand what the product does and where the business needs to go next.

For a core product request, the Engineer can:

  1. gather the relevant customer and company context
  2. turn the request into a scoped implementation brief
  3. identify dependencies, risks, and acceptance criteria
  4. prepare a prompt for your coding agent or a handoff for your engineering team
  5. use the completed product change as context for launch, sales, support, or operations work

Existing Managed App Workspaces

The product boundary above is the default for new work. Existing workspaces that already use Cofounder's managed app stack can continue using the supported app repository, sandbox, Supabase, database viewer, preview, and publishing workflows documented below.

Testing Changes Locally

The Engineer can test managed app changes in a sandbox before you review a PR.

That means it can make a change, run the app locally, open the app in a browser, and check the affected flow before handing the work back to you.

This is especially useful for:

  • product flows that need clicking through
  • UI changes that should be checked visually
  • forms, dashboards, and authenticated screens
  • database-backed features
  • Supabase migrations or schema changes

For browser testing, the Engineer opens the local version of the app inside its sandbox and interacts with it like a user. It can load changed pages, click through flows, fill out forms, check desktop and mobile layouts, and fix issues it finds before asking you to review.

You can ask for this directly:

  • Test the signup flow in the sandbox before opening the PR.
  • Click through the dashboard and make sure the new empty state looks right.
  • Check this change on desktop and mobile.
  • Run the app locally and include screenshots of the tested flow.

If the app requires a login, use a dedicated test account instead of your personal account.

When browser verification hits a login form and no saved credentials match, the Engineer can prompt you in the task to Save Credentials. That prompt stores the email or username and password securely for browser automation on that site. You can skip the prompt if you want the Engineer to create a local-only test user or seed data instead.

If browser verification runs into a login wall, missing account, missing organization, or empty test data, the Engineer should keep going when it can do so safely. It should use saved browser credentials, start local Supabase, create a local-only test user or seed data, and retry the browser flow instead of stopping at the first setup issue.

Local Supabase Verification

When a managed app change depends on the database, auth, or storage, the Engineer can run Supabase locally in the sandbox.

Local Supabase gives the Engineer a safe backend for testing app behavior without touching production data.

The Engineer can use it to:

  • apply and test migrations
  • confirm new tables or columns work with the app
  • create test data
  • test login and auth-dependent flows
  • verify database-backed UI before the PR is ready for review

For schema changes, the Engineer should still put migrations in the managed app repo and send them through the normal review and publishing flow.

For authenticated flows, ask the Engineer to create a local-only test user before browser testing. If the agent changes seed.sql, it should run supabase db reset against the local Supabase stack before retrying the browser flow so the running database sees the new seed data.

You can copy and paste this:

Set up a local-only test user for this app using seed.sql.
Then run supabase db reset locally so the seed is applied.
Run the app with local Supabase and use that test user to
browser-test the changed flow end to end.

Do not use my personal account. Use non-sensitive test data,
and include the local test login plus what you verified in your
final summary or PR notes.

Database Viewer

The database viewer lives on Canvas as the Database artifact in the Engineering workspace for existing managed app workspaces.

Use it to browse tables in the managed Supabase project from inside Cofounder. It also lets you upload a CSV file directly into one of those tables without leaving the Engineering workspace.

The Database artifact lets you:

  • browse tables in the managed Supabase project
  • open a table and see its records
  • upload a CSV file into the currently opened table

To upload a CSV:

  1. Open Canvas.
  2. Open the Engineering workspace.
  3. Open the Database artifact or Database tab.
  4. Pick a schema and open the table you want to import into.
  5. In the table view, click Upload CSV in the header.

The import flow walks through file selection, header mapping review, and import. Rows are appended to the table. Existing rows are not touched, and the import does not truncate or replace data.

CSV imports expect a standard .csv file with a header row. Headers must match columns on the target table, and the importer rejects unsupported mappings such as generated columns, unsupported identity columns, array columns, unknown columns, or missing required columns.

Empty cells for non-text columns are treated as "not provided", so column defaults and nulls still apply. If some rows fail validation, Cofounder reports row-level errors so you can fix the CSV and run the import again.

Previews And Feedback

When the Engineer builds a website, internal tool, or technical marketing artifact, Cofounder can show a preview in the workspace.

Use the preview to review the result before it goes live. Leave direct feedback on the affected UI when available, or ask for a specific revision in the task.

For user-facing work, ask the Engineer to verify the affected flow before handing it back. It should report what it tested, what passed, and any remaining manual review.

Publishing Website Work

When website work is ready, the Engineer can prepare it for review and request a deploy to staging. You approve that handoff, review the staged result, and then use the workspace publishing flow when it is ready to go live.

See Requesting a deploy and Publishing.

Review Before Shipping

Review consequential work before it ships, especially:

  • analytics, payment, or customer-data handling
  • secrets, permissions, and external-service changes
  • user-visible copy and UI
  • sends, publishes, or production changes
  • checks the agent could not complete

Next Steps