Can I take a requirement straight to a developer in a meeting, or does it have to go through the PM?

You can talk to developers directly, but the conclusion has to land with the PM. What a developer hears in a meeting often reflects only the part they own; the front-end version and the back-end version of a request may not match, and adjustments agreed face to face easily skip the scope and schedule assessment. The steadier approach: clarify technical details with the developer in person, such as whether a field is required or whether a report must update in real time, then ask the PM to write the outcome into the requirements document or change log and confirm the effect on schedule and scope. That gives you a record if there is a dispute later, and avoids the "but I told so-and-so" situation.

The vendor says their team is lean and one person covers several roles. Is that acceptable?

Yes. A lean team is not a problem in itself; the problem is whether it is clear who covers what, and whether the key roles still check each other's work. Before the project starts, ask the vendor for a role map: who is the PM, who designs, who writes the front end and back end, who tests, and who manages launch and hosting. If the same person writes the code and is the only tester, agree on an extra acceptance step, such as someone on your side or another colleague walking through the test checklist. Also ask who takes over if that person is on leave or leaves, and whether source code and documentation are always kept somewhere you can see, so the knowledge does not live only in one person's head.

Who on the client side needs to be involved in the project?

At minimum, one project contact with decision-making authority who settles requirement trade-offs, answers questions, and signs off on acceptance. That person does not need to be technical, but they must be able to decide on behalf of the company, and how quickly they respond directly affects the schedule. Beyond that, bring in one or two actual users for requirement interviews and acceptance, depending on what the system does, such as customer service, warehouse, or sales assistant staff, because they know the exceptions best. If the system touches accounting, personal data, or integration with existing systems, have accounting, legal, or internal IT review it at the relevant stage. You do not need many people, but each person's scope should be clear, and their participation should count as part of their workload rather than being piled on top of it.

Software Project Team Roles, Explained Plainly

Clients outsourcing software for the first time often run into this scene at the kickoff meeting: four or five people show up, their business cards say PM, UI/UX, front end, back end, and QA, and you understand about half of what each of them says. After the meeting you want to add a requirement but are not sure whom to message. Just before launch you discover a screen does not look the way you imagined, and you cannot tell whether the problem lies in the design or the code.

Understanding software project team roles is not about managing engineers yourself. It is about handing the right information to the right person at the right time. The same comment, “this button feels off,” gets handled completely differently depending on whether it reaches the designer, the front-end developer, or QA.

Below we walk through what each role does, what to tell each one, how to arrange contracts and meetings around them, and finally what to watch for when a small team has one person covering several roles.

The big picture: who a feature passes through on its way to launch

A concrete example ties it together. Imagine a company that wants to add online booking to its website. Inside the team, the work flows roughly like this:

The PM interviews you: who books, which options they choose, who gets notified after a booking, whether bookings can be canceled. The PM turns this into a requirements document and splits it into work items that can be scheduled.
The UI/UX designer draws the flow and the screens from those requirements: where the booking entry sits, how a time slot is chosen, how error messages appear. You review and approve them.
The back-end developer designs how data is stored, how slot conflicts are detected, and how notification emails go out, and exposes interfaces (APIs) for the screens to call.
The front-end developer turns the designs into a working web page, connects it to the back-end interfaces, and handles different screen sizes. If the feature also goes into an app, an app developer handles the mobile side.
QA tests against the requirements and designs: the normal flow, double bookings, full slots, a dropped network connection, and reports problems to the right developer.
Operations (DevOps or system administration) deploys the code to production, sets up the domain and certificates, handles backups and monitoring, and is the first to get the alert when something breaks after launch.

In this chain, your main points of contact are the PM and the designer; the other roles mostly work behind the scenes. But knowing the whole line tells you which station a problem is stuck at.

The PM: your main point of contact

The PM (project manager) is the person you deal with most. Some teams also have a PO (product owner) or a systems analyst, but from the client’s point of view the core job is the same: translate your needs into work the team can execute, and own the schedule and scope.

A PM usually:

Runs requirement interviews and writes up the requirements and feature scope.
Sets the schedule, breaks down the work, and tracks progress on each item.
Collects and assesses change requests, explaining the effect on schedule and scope.
Reports regularly on progress, risks, and decisions you need to make.
Arranges acceptance and pre-launch confirmation.

What to tell the PM: every decision about what to build, what not to build, and what comes first, plus every requirement change. Even if you agreed an adjustment with a developer in a meeting, ask the PM to record it. For how to raise and assess changes, see Managing Change Requests in Software Projects.

Signs of a capable PM: at every meeting they can say clearly what is done, where things are stuck, and what they need you to decide. When you raise a change, they explain its impact before agreeing, rather than saying yes or no on the spot.

UI/UX design: what users see and how they operate it

UI is the user interface (how the screens look); UX is the user experience (whether the flow feels smooth). On small teams one designer usually covers both; larger projects split them further.

The designer:

Maps the user flow: where people come in, how many steps they take, and where they might get stuck.
Draws wireframes (structure-only sketches) and high-fidelity designs.
Defines component guidelines so buttons, forms, colors, and type sizes stay consistent across pages.
Hands designs and annotations to the front-end and app developers.

What to tell the designer: who the users are and in what situations they use the system, your brand tone and any rules that must not be broken (such as corporate colors), and what you like and dislike about competitor or reference sites. Most important, give all your feedback during the design stage. Changing the layout after the designs are approved affects front-end and back-end workload.

When reviewing designs, do not just judge whether they look nice; walk through the flow with real scenarios. For how to review them, see A Client’s Guide to Reviewing UI/UX Designs.

Front-end, back-end, and app developers: three kinds of “people who write code”

These three are the roles clients mix up most. A restaurant analogy helps:

Front end is the dining room: everything customers can see and touch, including the web pages, how buttons respond, form checks, and the mobile layout.
Back end is the kitchen: customers never see it, but it decides whether the dish can be made at all. It covers the database, business logic, permissions, payments and third-party integrations, and emails and notifications.
App developers are the delivery window: they get the same dishes onto phones, handling the separate rules of iOS and Android, push notifications, phone features such as the camera and location, and app store review.

Who to go to: a simple lookup table

What you see	Most likely whose area
Layout broken, buttons not responding, mobile layout jumbled	Front end
Data saved wrong, wrong calculation results, users seeing data they should not	Back end
Notification emails not sent, third-party integration failing	Back end (sometimes operations)
Errors only inside the app, push notifications not arriving, store rejection	App
The whole site will not open, is very slow, certificate expired	Operations

You do not have to diagnose this finely yourself; when reporting a problem, hand it to the PM or QA to assign. But knowing the split means you naturally include the key details, such as “on my phone,” “only for one account,” or “the email sent to customers.” For a reporting format, see How to Report Bugs to Your Vendor.

What to tell developers: most of the time, go through the PM. Direct conversations make sense for technical details, such as accounts and data formats in an existing system, application details for third-party services, or the business rule behind a particular field. Afterward, remember to update the PM.

QA: the people whose job is finding problems

QA (quality assurance) handles testing. Many clients ask whether developers can test their own work. They can, but a developer tests whether what they wrote runs the way they understood it, while QA tests whether the system breaks under the requirements and real usage. The angles are different.

QA usually:

Writes test cases from the requirements, covering normal flows and exceptions.
Runs them item by item in the test environment and records the results.
Reports problems, tracks fixes, and verifies again after each fix (regression testing).
Runs an overall smoke test before launch to confirm the main features still work.

What to tell QA: the situations you most fear going wrong, and the exceptions real users will hit. For example, “customers often book and then change the time” or “accounting exports the whole month at once at month-end.” That is exactly the information QA lacks most when writing test cases.

Note that QA testing does not replace your own acceptance. QA confirms the system works to the specification; your acceptance confirms the specification itself fits your business. For how to arrange it, see How Software Acceptance Works.

Operations: keeping the system alive after launch

Operations is often called DevOps, SRE, or system administration. It owns the world after the code is written:

Planning and building servers or cloud environments, separating development, testing, and production.
Setting up automated deployment so updates can go live safely and be rolled back if something breaks.
Managing domains, SSL certificates, and database backups.
Setting up monitoring and alerts so someone knows immediately when the system slows down or goes down.
Handling security updates and access permissions.

This role is the easiest to overlook early in a project, until just before launch when it turns out nobody is responsible for hosting and nobody can say whose name the domain is under. For the concepts of environments and deployment, start with Development, Staging, and Production Environments Explained.

What to tell operations: who owns the domain and hosting accounts, expected usage and peak times, data retention and backup requirements, how quickly you want to be notified when something goes wrong, and who can be woken up in the middle of the night. These are best settled in the contract and before launch, not patched in afterward.

Client communication map: route things this way and nothing gets lost

Here is the content above as a table you can use directly. At the kickoff meeting, ask the vendor to fill in the actual person’s name and contact details for each row:

What you need to handle	Main contact	Information to prepare
Add or drop features, change priorities	PM	What to change, why, how urgent
Check progress, schedule, risks	PM	The milestones you care about
Screens, flows, copy direction	Designer (scheduled through the PM)	Usage scenarios, brand rules, reference examples
Existing system data, third-party accounts	Back end (keep the PM informed)	Accounts, documents, data samples
Report a problem	PM or QA	Steps, screenshots, device and account
Acceptance and sign-off	PM	Acceptance checklist, real users
Domain, hosting, backups, emergencies	Operations (keep the PM informed)	Account ownership, who to notify

Three practical principles on top of that:

One contact facing one contact. Name one main contact on your side to pair with the vendor’s PM. Others can take part, but decisions go out only through these two people.
Verbal conclusions become written ones. After each meeting the PM sends minutes, you reply to confirm, and any discrepancy gets corrected right away.
Know who is on leave. Ask the PM to note key people’s leave and their backups in progress reports, so you do not find out the back-end developer is away the week before launch.

For what to prepare before the project starts and what to ask at kickoff, pair this with The Client’s Pre-Kickoff Checklist for Software Projects.

Small teams with people wearing several hats: fine, but name the risks first

Not every project needs one person per role. For a small website or an MVP, a common setup is a PM who also designs, one full-stack developer writing both front and back end, and operations handled by that developer on the side. There is nothing inherently wrong with this. What matters is that you know who covers what, and which steps have lost a check.

Risks that come up in practice:

Player and referee at once: the same person writes the code and tests it, and cannot catch their own blind spots. The fix is to agree that someone else, or you, runs through the test checklist.
A PM who also codes: when coding gets busy, progress reporting and requirement work are the first things sacrificed. The fix is a fixed reporting rhythm, such as weekly, in a fixed format.
Single point of dependency: all the knowledge sits with one person, and if they fall ill or leave, the project stops. The fix is requiring source code in a version-control platform you can see and documentation updated as work progresses, not written up at the end.
Nobody owns operations: after launch, hosting, certificates, and backups become something “the developer is probably handling.” The fix is spelling out operations responsibility in the contract, or arranging a separate maintenance plan.

With a lean team, you can ask these questions directly:

Who actually fills each role on this project? Is anyone covering several?
Who tests? Besides the person who wrote the code, who verifies it again?
If a key person takes leave or leaves, who takes over, and how long would the handover take?
Where are the source code, designs, and documents kept? Do I have access at all times?
Who is responsible for hosting and monitoring after launch?

If you want someone technical on your side to judge whether a team setup makes sense, look at how a fractional CTO service works. If you are still choosing a vendor, How to Choose a Software Development Company also lists questions for evaluating team composition.

Closing: knowing who owns what removes most communication costs

You do not need to learn to code, but knowing what each role on the team does makes every conversation more precise: requirements go to the PM, screens to the designer, problems to QA for assignment, and hosting and emergencies to operations. Most project friction is not something technology cannot do; it is information going to the wrong person, or getting distorted along the way.

If you are about to start a software project and want to work out which roles you need, which can be combined, and who on your side should take part, NETVANA can help you plan, starting with team setup and the communication flow. We have no fixed packages; software work is quoted after a consultation, and we explain the actual staffing for your project’s scope before discussing how to work together. Contact us, or first look at the software services overview to see what we cover.

Further reading: For what to prepare before the project starts, see The Client’s Pre-Kickoff Checklist for Software Projects. For how to write requirements for the PM, read How to Write Software Requirements. For a method for reviewing designs, see A Client’s Guide to Reviewing UI/UX Designs. For a bug reporting format, read How to Report Bugs to Your Vendor. For what you should get back when a project closes, see Source Code Ownership and Project Handover.