How to run a web or app project remotely without losing control of scope, quality or timeline.
Most New Zealand web projects now run remotely, at least partly. Done well it is indistinguishable from working in the same room. Done poorly it produces the classic outcome where everything seems fine until the reveal at the end.
Insist on seeing working software early
The single biggest risk in remote projects is a long silence followed by a big reveal. If the first thing you see is a finished site in week six, any misunderstanding from week one has been built on for a month.
- Ask for a live staging link from the first week, however rough
- Expect to see something new at least weekly
- Click through it yourself rather than watching a demo. You will find things a demo skips.
Communication that works
- One written channel of record, so decisions are searchable later.
- One short scheduled call a week rather than ad hoc calls whenever something occurs to someone.
- Decisions confirmed in writing, even the ones made verbally.
- One named contact on each side.
Timezones
If your team is offshore, the overlap window matters more than the total hours. A team in a nearby timezone with four overlapping hours is easier to work with than a cheaper one twelve hours out, where every question costs a day.
This is a real argument for New Zealand or Australian teams on projects needing frequent decisions, and a weaker one for well specified projects that need fewer conversations.
Protecting yourself
- Make sure code lives in a repository you can access, not only on someone's laptop
- Get accounts created in your name from the start rather than transferred later
- Keep your own copy of design files and content
- Pay in milestones tied to things you can verify