Now taking builds. Scope returned within 48 hours. Start yours →
Now hiring

Build Architect

Product manager, scrum master, QA lead, stakeholder rep, and developer by proxy — all in one person. You take a brief from a real business, own it completely, and hand over something that works and that they own permanently. Remote, project-based, no bureaucracy.

What the role actually is

A build architect is, in a single person, a product manager, a scrum master, a QA lead, and a stakeholder representative — and also a developer, but by proxy. That is not an exaggeration. It is the job description.

As the product manager, you translate a vague brief into a specific, bounded scope. You decide what is in, what is out, and why. As the scrum master, you own the delivery: no one is unblocking you or checking in on your progress. As the QA lead, you are responsible for what ships — you test it, you validate it, you do not hand over something you have not verified works. As the stakeholder representative, you make decisions on behalf of the customer throughout the build, the way a good product person holds the user's perspective even when the user is not in the room.

The developer part is real but it works differently here. You will use AI tools as your primary building mechanism, with the Merebase core providing the structure and guardrails. You are not writing PHP from scratch all day. You are directing, reviewing, and validating what gets built — which requires that you understand the platform, the data layer, and the implications of the decisions being made. You need to know when the output is right and when it will fail in a production environment owned by a real business.

What makes someone good at this role is not primarily their ability to write code. It is their ability to understand a business operation, ask the right questions, make confident decisions under ambiguity, and take full ownership of the result from brief to handover.

What matters most

Business and data thinking

  • Understanding what a business actually needs, not just what they asked for. The brief is a starting point, not a specification.
  • Data architecture for simple apps: what to store, how to structure it, and what it means when this app needs to share data with another.
  • Knowing when two apps should be connected and what a shared data layer looks like in practice.
  • Scoping with precision: a scope that has no ambiguity about what is and is not included, written so a non-technical customer can understand it.
  • Saying no to scope creep with a clear explanation of why the boundary exists and what would change if it moved.

Technical foundation

  • PHP understanding: enough to read and reason about code, catch problems in AI output, and know when something is structured correctly.
  • WordPress as an application platform: custom post types, user roles, the REST API, how plugins are structured, how data lives in the database.
  • MySQL basics: schema design, understanding relationships between tables, knowing when a query is going to be a problem at scale.
  • Security fundamentals: input validation, capability checks, prepared statements. Non-negotiable on every build.
  • Git and handover: version control always, documentation clear enough that any developer can pick it up later.

What you get

Project-based pay
Paid per completed build. No timesheets, no hourly rates. Scope it, build it, invoice it.
Fully remote
Work from wherever you work well. No office, no fixed hours, no mandatory standups.
Interesting briefs
Real small businesses with real problems. Every build is a different domain, a different workflow, a different set of constraints.
Tight scope, no drift
Builds are scoped before they start. You are not managing customer expectations mid-build, that work is done at scope stage.
No support retainer
Once a build is handed over, it belongs to the customer. You are not on call for it indefinitely.
Work that lasts
Every app you build runs on infrastructure the customer controls. It does not disappear when a vendor changes terms. It keeps running.

Who this is not for

  • People who want to own the customer relationship long-term or build toward an ongoing retainer. Each build ends at handover. That is the model.
  • Anyone who needs the brief fully specified before they can start. Real briefs are incomplete. Part of the job is asking the right questions to fill the gaps.
  • Developers who use AI as a black box. The Merebase core provides the structure and guardrails, but you need to understand what is being generated well enough to know when it is right and when it will cause problems in production.
  • Anyone who treats security as a final step or someone else's concern. Builds go directly to production environments owned by real businesses.
  • People who need weeks per build. The scope is designed to be deliverable in days. If the economics of that do not work for how you work, this is not the right fit.

How to apply

No CV. No cover letter. Build something instead.

Pick a real small business problem that does not have a good tool yet. Write a one-paragraph scope for it: what the app does, what it does not do, who it is for. Then build it as a working WordPress plugin and publish the repo on GitHub. That is the whole application.

Use AI to help you build it. We expect you to. What we are looking at is whether you understood the problem, whether the scope was honest, and whether what you shipped works correctly on a real WordPress install.

01 Pick a single-job business problem. Something a real business would pay to have solved, built for them specifically.
02 Write a one-paragraph scope: what it does, what it deliberately does not do, and what the business gets.
03 Build it as a working WordPress plugin. Use AI tools to help. Publish the repo on GitHub, or invite us to install it privately.
04 Email us the link. Include your scope paragraph and a couple of sentences on why you picked that problem.
careers@merebase.com

We review every submission ourselves. No automated screening.