Developer deliverables every non-technical client should insist on
When you invest in a new website or mobile app, you’re not only buying a set of features. You’re buying the ability to operate what’s been built, improve it over time, and-if needed-switch suppliers without your business grinding to a halt.
At Jensen Technologies, we’ve been delivering web and app projects for many years. The most painful issues we’re asked to fix after the fact are rarely “bad code” in the abstract. They’re usually missing deliverables: unclear ownership, no deployment documentation, inaccessible source code, or a handover that amounts to “message us if anything breaks.”
This post is a practical checklist you can use before signing a proposal, during delivery, and especially at handover.
1) Access & ownership (make this non-negotiable)
If you don’t control access, you don’t control the product. Make sure you receive (and test) the following:
- Domain registrar access and control of DNS (or written confirmation that you own the domain and can move it anytime).
- Hosting/cloud access (AWS/Azure/GCP/Vercel/Netlify/etc.), ideally under an account owned by your company.
- Source code repository access (GitHub/GitLab/Bitbucket) under your organization, not a private repo only the agency controls.
- Admin access to relevant tools: CMS, analytics, tag manager, email service, payment provider, and any third‑party integrations.
- Mobile app store access (Apple Developer / Google Play Console) for mobile apps-again, owned by your company.
Practical tip: don’t just receive credentials; plan a quick “access verification” session where you log in and confirm you can see what you need.
2) A usable codebase, not just a zip file
You should be able to run the project again in six months without guesswork.
- README documentation that explains how to run the project locally and how to build it.
- Environment variables documented: what values exist, what they do, and where they’re stored.
- Dev/staging/production clarity (even if staging is lightweight). You need a safe place to test changes before affecting customers.
If someone says, “It only works on my machine,” documentation and environment setup are usually the missing pieces.
3) Design deliverables you can actually reuse
Even if you’re “done with design,” you will revisit it-new landing pages, new flows, new features.
- Final design files (typically Figma) including components and styles, not only exported images.
- Brand essentials: colors, typography, spacing rules, icons and usage notes.
- Key user flows listed (sign-up, checkout, booking, etc.) so future work doesn’t accidentally break them.
4) Testing evidence (not just “we tested it”)
Testing shouldn’t be a mystery. Ask for clear evidence of what was tested and what wasn’t.
- Smoke test checklist for launch day (critical paths that must work).
- Automated tests where appropriate (unit/integration/end-to-end). Even a small starter suite helps prevent regressions.
- Support statement for browsers/devices: what’s included, what’s excluded, and why.
5) Deployment steps, rollback, and “where to look when it breaks”
Many project handovers fail at the exact moment you need speed: a bug in production, a campaign landing, a post-launch tweak.
- Step-by-step deployment process: who does what, with links to pipelines or scripts.
- Rollback procedure that brings the site/app back to a known good version.
- Logging and monitoring basics: where logs live, what alerts exist, and what “normal” looks like.
6) Security and compliance essentials
You don’t need a legal thesis, but you do need clarity.
- SSL/TLS enabled and basic security headers where applicable.
- Roles and permissions documented (who can deploy, view data, manage users, etc.).
- Data handling notes: what personal data is collected, retention expectations, and backup policies.
7) Maintenance handover (how the product stays healthy)
The launch is the start of operations, not the end of development. A good supplier will make ongoing responsibilities transparent.
- Dependency update plan (monthly or quarterly) and how vulnerability fixes are handled.
- Backups: schedule, retention period, and confirmation that restores have been tested.
- Monitoring/uptime alerts and a clear recipient list.
- A “first week after launch” plan covering bug triage, small fixes, and performance tuning.
Simple red flags to watch for in proposals
- “We’ll host it under our account for convenience” without explicit ownership and export/migration terms.
- No mention of documentation, testing, or deployment-only features and design.
- Vague maintenance language like “as needed” without scope, response times, or what’s excluded.
- No list of deliverables beyond “website/app,” which makes acceptance subjective and messy.
A healthy project handover feels almost boring: access is clear, documentation exists, and a different team could step in if your needs change.
If you’d like to discuss your own project, Jensen Technologies can help you define the right deliverables for your stack (web, mobile, and AI-enabled products), review proposals, or put a clean handover process in place. Get in touch if you’d like to talk it through or need help applying this in your business.