One person, whole features
Features are handed over as outcomes
The most effective way to brief a full-stack developer is a user story with an acceptance list, not a technical task. "A manager can approve or reject a leave request and the employee gets an email" is enough. The developer decides on the table changes, endpoint, components and tests, writes a short plan in the ticket and builds it as one vertical slice. You review working software on a preview or staging URL, not a back end that will have a screen one day.
What happens in the first two weeks
On an existing codebase, the developer sets up the project, reads the data model and ships two or three small slices that touch both ends, which tells everyone quickly whether conventions are understood. On a new product, the fortnight goes into foundations that are dull to demo and expensive to change later: authentication, roles, the base layout, the deployment pipeline and a staging environment. By the end you can log in to something real.
A typical week
Plan on Monday, slices delivered to staging through the week, a review with you when there is something to click. Each slice is one pull request containing migration, server code, interface and tests together, which makes review easier and rollbacks clean. Written updates follow the model you chose in the table on this page. Questions come to you directly in chat, since a developer who owns the whole feature needs quick answers about how the business works.
Where one person stops being enough
A full-stack developer is a builder, not a department. They can follow a design system but should not be your product designer. They test their own work, but independent QA finds different bugs. And one person cannot be reviewer and author at once, so a second developer on our side reads their pull requests unless you have engineers who will. When the roadmap needs parallel work, design and formal testing, it is time to look at a dedicated development team.
Judging fit
After a month, count finished features, not hours. A good full-stack developer delivers things users can use, leaves both ends equally tidy and asks about the business more than about the tools. If the interface is polished and the API is fragile, or the reverse, you have a specialist stretched too far, and you should ask us for a different match. For broader context, see our web application development service.