Weekly update
A written note each week covers what shipped, what is next, and any decision we need from you. You do not have to attend a meeting to know the status.
Process
From idea to impact.
You always know what is in scope, what happens this week, and who owns the next decision.
01
Discover
Discovery is a structured conversation, not a long workshop for its own sake. We review what you have today, who the users are, and what a successful release has to change in the business.
- Stakeholder call and a review of existing sites, apps, or documents
- Users, markets, and the job the product has to do
- Constraints: timeline, budget band, hosting, compliance, and languages
- A short findings note you can share internally
02
Plan
The proposal names what is in the first release, what is explicitly out, and how we will know the work is done. Fixed-scope projects get a milestone plan. Dedicated teams get a staffing plan and a cadence.
- Scope, assumptions, and exclusions in plain language
- Milestone dates and what each milestone delivers
- Risks we can already see, and how we will handle them
- The engagement model and a quote
03
Design
We map the flows, then design the screens your customers and staff will actually use. You review prototypes, not surprise visuals on launch week. Where a design system already exists, we extend it.
- Sitemap or product map and the primary user flows
- Wireframes, then a clickable prototype of the key paths
- Visual design aligned to your brand, or a new system if you need one
- A written sign-off before engineering builds past the agreed screens
04
Build and test
Work is tracked on a shared board. You see progress every week, and you can click through a staging environment rather than wait for a single big reveal. Testing covers the agreed browsers, devices, and critical paths.
- A staging environment from early in the build
- Weekly written status: done, next, and blocked
- Code review inside the team before work is called complete
- Functional, content, and responsive checks against the scope
05
Launch and support
Launch is a checklist: DNS, TLS, backups, analytics, redirects, and a rollback path. After go-live we watch the release, fix defects in the agreed scope, and train the people who will run it.
- Launch checklist and a rollback plan
- Credentials and repositories transferred to you
- A short training session for editors or administrators
- A warranty window, then an optional retainer
Communication
Shared project board
Tasks, owners, and due dates live on a board you can open. We use your tool if you already have one. Otherwise we set one up and invite your team.
Dedicated project manager
One person is accountable for schedule, scope, and the conversation. Engineers stay focused on the build. You still have a direct line when a technical decision needs you.
Agreed hours
Meetings are booked inside an overlap that works for your region and ours. Async updates cover the rest, so a question asked at the end of your day is answered at the start of the next.
Quality assurance
- Scope is the test plan. If it is not in the agreed flows, it is not assumed.
- Pull requests are reviewed by someone who did not write the change.
- Staging is checked on current versions of Chrome, Safari, Firefox, and Edge, plus the phone sizes named in the scope.
- Forms, payments, and permissions get an explicit pass before launch, including the empty and error states.
- Performance budgets are set for marketing pages: compressed images, limited third-party scripts, and a build you can explain.
- Content is reviewed for broken links, missing titles, and placeholder text before a site is called done.
Security practices
NDA
A mutual non-disclosure agreement is available before discovery and is standard for white-label and product work. We do not need your customer data to write a proposal.
Secure access
Production access is limited to the people who need it, protected with individual accounts and multi-factor authentication where the platform allows it. Shared passwords in chat are not how we work.
Code ownership
Repositories, design files, hosting accounts, and domains are created in your name whenever you want them to be. On final payment for the scope, ownership of the deliverables transfers to you.
Dependencies and secrets
Secrets stay in environment configuration, not in the repository. Third-party packages are reviewed before they are added, and we remove keys from anywhere they do not belong before handover.
After launch
- A warranty period for defects against the agreed scope, stated in the proposal.
- Optional monthly retainer for updates, uptime checks, backups, and small changes.
- A documented handover: architecture notes, how to deploy, and who to call.
- A path back for the next release, so you are not starting vendor selection again.