What needs to become interactive?

You may need to evaluate a product idea in the browser, implement a designed flow, or resolve details in an existing interface. We begin by defining what needs to work and what “finished” means for that piece.

If the user tasks and screen structure are still undecided, start with product design before implementation. Design decisions can be part of a combined scope, but we identify them before treating a mockup as a build specification.

Build the behavior as well as the layout

A screen reference needs supporting decisions: what happens when someone submits a form, when data is missing, or when an action fails? I bring the relevant interactions and interface states into the implementation scope.

Depending on the project, deliverables can include:

  • A defined flow, its design references, and completion criteria.
  • Working interface components and agreed responsive behavior.
  • Loading, empty, error, and success states relevant to that flow.
  • Clearly identified sample data or agreed live connections.
  • An agreed set of screen, device, and interaction checks.
  • Source code, required access, and delivery notes within the agreed scope.

For example, a dashboard built with sample records can help review navigation and interactions. Connecting it to live business data introduces additional requirements that need to be agreed.

Choose a prototype or a defined implementation

Working prototype: A focused environment for exploring a journey or interaction. We specify what is simulated and what works, so the prototype can be assessed for its intended purpose.

Defined interface build: Implementation of agreed screens, components, states, and connections. Existing product requirements and the responsibilities of other developers form part of the scope.

Design and build: When interface decisions are also needed, we can scope the design work alongside implementation. Design-only support is available through the product design service.

A prototype is not automatically ready for production use. Deployment, live data, access controls, operational requirements, and maintenance need explicit decisions before that commitment is made.

For a complete marketing or business site, see website design and development. For phone-specific journeys, see mobile app design and development.

Where AI coding tools fit

I use tools such as Claude Code, Codex, and Cursor where appropriate to support implementation and iteration. The starting point remains the design reference, expected behavior, and agreed scope.

Before the build, we define how the working flow will be reviewed: the states to cover, the reference screens, and the checks needed for its intended use. Review findings can then be used to agree corrections before handoff. A specific tool’s involvement does not establish that those checks have passed.

We also record the handoff destination, any setup instructions, known limitations, and responsibility for the next stage. The checks and delivery steps for your project are agreed in its scope.

Questions about implementation and handoff

Can you implement an existing Figma design?

We can assess your design as the starting point. I review the required screens, states, interactions, and technical environment before confirming the implementation scope.

Can we begin with a working prototype?

Yes. We define the journey to explore, what can be simulated, and which parts need to work. Moving from that prototype to production requires its own requirements and scope.

What is included in a build?

The agreed screens, states, interactions, and connections. Authentication, payments, data services, deployment, and other dependencies are included only where assessed and explicitly agreed.

How do you review AI-assisted code?

We define the review requirements for the implementation before work begins, including relevant visual references, behavior checks, and technical review responsibilities. Any specialist or independent review needed for the intended use must also be scoped. I do not treat generated output as evidence that those checks are complete.

Who receives the code and maintains it?

The agreement records the source code handoff, repository or account access, and any third-party dependencies. Maintenance responsibility and further changes are defined separately.

How do you estimate the work?

From the flow boundaries, design readiness, technical dependencies, review requirements, and handoff responsibilities. Share those inputs so we can define a proposal.

Share the design and what needs to work

Send the design reference or current interface, describe the flow you want to implement, and tell me whether the goal is a prototype or a working part of your product. Include any existing codebase or team constraints.