1
Start with project tracking in Plane
We will use Plane to track the work that matters: projects, tasks, meeting notes, decisions, bugs, and follow-ups. Every project should have a clear board, clear ownership, and enough context for another developer to understand where things stand.
- Each project gets a Plane project before development begins.
- Work is broken into tasks that are small enough to review and move.
- Meeting notes and action items are saved against the project, not left in chat.
- Completed work must be traceable to a task, pull request, test, or deployment.
2
Project initialization before we write code
Before we begin a project, we will run a mapping session. This will be a one-on-one with me so we can clarify the scope, the risks, the first tasks, and what success looks like.
- Define the problem and the expected business result.
- Map the main workflows, integrations, and user journeys.
- Agree on the first milestone and what should not be included yet.
- Create the Plane project, initial tasks, and documentation checklist.
3
Align on the Hokela vision
The work we do should connect back to the bigger Hokela direction. We are not just shipping isolated features; we are building a platform around a few strong pillars.
Agents on Demand
Operational support and field execution that can scale when clients need people on the ground.
Retail Network
A connected retail layer that helps us reach customers, merchants, campaigns, and distribution points.
Wallet
Extend the wallet beyond payroll payments into broader payments, usage, and account value.
Rewards
Build marketing and campaign tools that can support brand activations, including examples like Weetabix.
4
Set the engineering quality baseline
Good delivery is not only about finishing tickets. We need observability, documentation, and tests to be part of the normal workflow.
- Logging should be planned from the start, with Grafana dashboards for important flows.
- Code documentation should live with the project in Plane and the repo.
- We will use an automated JSDoc script to turn code comments into developer documentation.
- Each project should show documentation coverage as a percentage so gaps are visible.
- Deployment pipelines should include tests, with Playwright as the default for browser flows.
5
Keep space for monthly brainstorming
Once a month, we will step back from tickets and talk about what we are seeing: product ideas, delivery problems, technical debt, customer needs, and ways to improve how we build.
- Bring one improvement idea, one risk, and one thing we should stop doing.
- Convert good ideas into Plane items only when they have a clear next step.
- Keep the session honest, practical, and connected to the Hokela pillars.
Close the meeting
Once we agree on this structure, I will start using it for follow-up. Plane will be where we track the work, the decisions, the owners, and the delivery health. The goal is not more process. The goal is fewer loose ends.