What to Prepare Before Starting a Development Subscription
A development subscription starts working on day one. Whether it starts working well depends partly on what you've prepared beforehand.
This isn't a lot of work — an hour or two — but it makes a significant difference to the quality and speed of the first few tasks.
Your codebase access
The developer needs access to your repository. Before starting:
- Share your GitHub/GitLab/Bitbucket repository with your developer's account
- Confirm the main branch name and any branch naming conventions you use
- Share access to any private packages or submodules
If you don't have a repository yet (greenfield project), let the developer know — they'll initialise it as part of setup.
Deployment access
Your developer needs to be able to deploy. Depending on your setup, this might mean:
- Vercel project access (invite as a developer)
- Netlify, Railway, Render, or equivalent access
- SSH access if you're on a VPS
- Environment variables for production/staging environments
It's worth setting up a staging environment before starting if you don't have one — being able to deploy and review work without touching production is valuable.
Design assets
If tasks will involve implementing UI, share your design assets:
- Figma file — share with view (or edit) access
- Design system — Figma library, Storybook link, or a doc describing components and patterns
- Brand assets — logo files, colour codes, font details
- Screenshots or recordings of existing UI if relevant
Not every task needs Figma specs. But having them ready when they're needed is faster than sourcing them mid-task.
Your first 5-10 tasks
Spend an hour writing your first batch of tasks before the subscription starts. This means:
- No idle time at the beginning while you think of things to brief
- The developer can start immediately
- You can assess whether the task briefing format works for both of you early, and adjust
Tasks don't need to be perfect. A clear description of what to build, what done looks like, and any relevant assets is enough.
If you're not sure what to prioritise, start with the task that would add the most value to the product if it were done this week.
Context documents
A one-page product context doc saves hours of explanation across the life of the subscription. It should cover:
- What the product does (two sentences, for whom, solving what problem)
- Tech stack (frontend framework, backend, database, hosting)
- Conventions (any naming conventions, folder structure, CSS approach)
- Current priorities (what the product is focused on right now)
- Known issues or constraints (anything the developer should know about before touching the codebase)
This doesn't need to be polished. A Notion page or even a message is fine.
Communication setup
The subscription is async by default. Set up your communication channel:
- Share access to your task management tool (Notion, Linear, GitHub Issues, Trello — whatever you use)
- If you don't have one, create a simple board for the subscription: a backlog column, in-progress, and done
- Decide how you'll leave feedback (board comments, Loom replies, Slack, email — whatever suits your workflow)
The onboarding call
The first meeting of a Hardlite subscription is a 30-minute onboarding call. It covers:
- Walking through the codebase (or greenfield setup)
- Confirming the stack and deployment setup
- Reviewing the first batch of tasks
- Agreeing on communication preferences
After that: async by default. Work starts, and you'll see the first deliverable within 1-3 business days.
The preparation above means that call goes smoothly and work starts without delays.