Developer Expectations: 7 Questions to Ask on Your First Day

The hardest problems I've run into on client projects were rarely technical. They were expectations nobody had written down. Who owns the layout? What does finished mean on Friday compared to the final deadline? Which screens exist only in someone's head? When a team answers those questions differently without realizing it, a project can ship on time, work well and still leave people feeling it went wrong.

The risk is highest when you join after the design is already approved. The designer has moved on, the client has signed off, and the team has formed opinions you weren't around to hear. It's also becoming more common. Design engineer is one of the faster growing titles in product teams, and AI tools have blurred the line between designing an interface and building one. Many teams now expect developers to own design decisions as well, but few say so out loud.

I learned this on a project in the past where I joined right after the client approved the design, built the product to match it closely and delivered on schedule. The client was happy with the result. Inside the team, it turned out several people had pictured my role differently, and we only discovered that at the first demo. Since then I've brought the same seven questions to the start of every project, and they're the ones I'd recommend to any developer joining work that's already in motion.

1. Ask whether you're implementing the design or sharing ownership of it. Some teams want the approved design built exactly as it is. Others expect the developer to improve spacing, hierarchy and layout along the way. Both are reasonable, and they lead to very different work. If you assume the first and the team expects the second, you'll deliver a faithful build that still disappoints. Ask the question in plain words in your first meeting and write down the answer.

2. Compare the design files with what a launched product needs. It's natural to check your build against the files. It's just as important to check the files against reality. Designs often leave out the landing page, empty states, error pages, account settings and access control. I once had to research and build a full landing page close to delivery because it had never been designed. A short checklist on day one turns that kind of surprise into a planning conversation.

3. Define what done means at every milestone. A demo ready build and a production ready build are different targets, and deadlines tend to drift toward the earlier one without much warning. For each date in the plan, ask what has to be true by then: clickable screens, working integrations, a deployed product or a polished one. When a date moves, ask the question again.

4. Ask about the budget for outside services before you research vendors. It's easy to spend days comparing enterprise grade APIs that meet every compliance and scaling requirement, only to learn the client's yearly budget covers a small fraction of the cost. Free or cheaper alternatives are often the right call for an early product, as long as everyone understands their limits. Knowing the budget first saves research time and makes your recommendations more credible.

5. Get the full list of integrations up front. Payments, email, analytics and third party data sources each affect the data model, the user flows and the testing plan. An integration that comes up halfway through the build is still scope, and it's much cheaper to plan for on day one. Ask for every external system the product has to talk to, including the ones that seem too obvious to mention.

6. Show a rough version in the first few days. This is the one I'd apply to myself first. Shipping fast is valuable, but a complete build shown for the first time near the deadline leaves no one a cheap way to change direction. A rough demo on day three brings unspoken expectations to the surface while they're still small. It also builds trust, because people can see progress instead of waiting for it.

7. Find out who signs off, and against what standard. The client may approve the design while the internal team judges the build by a different standard. If only one of those is written down, the other will show up at the worst possible moment. Ask who gives final approval and what they'll measure the work against, so everyone shares one definition of good before anything is built.

There's one piece of popular advice I only partly agree with. You'll often hear that a good developer should always improve the design while building it. When a client has already approved a design, quietly changing it isn't initiative. It's a scope decision made without the client. A better approach is to build what was approved and bring a clear list of suggested improvements to the people who can approve them. That respects the designer's work, the client's decision and the team's timeline at the same time.

None of these questions are complicated, and together they fit into one short meeting. They're easy to skip because everyone assumes the answers are obvious. They usually are, just not the same answers for everyone.

If you're joining a project after the design is done, bring these seven questions to your first meeting and get each answer in writing. Clear developer expectations at the start cost half an hour. Discovering them at the demo costs days, and sometimes some of the trust you earned by delivering quickly.