Vard CRM, a focused CRM for a freelance photographer

The short version

The problem

A freelance photographer friend was forcing project work through a generic Trello board.

What I did

Built a narrow CRM around his actual workflow. A status pipeline, linked clients, and a start page of next actions.

What it was worth

Finished and never used. He got employed first. The lessons about scope and AI-assisted building stayed.

The call

Kept the scope narrow on purpose. One real user's workflow, no agency features.

A freelance photographer friend was managing client work in Trello and was tired of forcing a project workflow into a generic board.

The problem was not that he needed a heavy sales CRM. He needed a calmer way to track clients, projects, status, and next actions without adding agency-style complexity.

The name Vard comes from the Nordic "Varde", a stone cairn built to guide travellers and mark the way. That felt right for a small CRM meant to make the next practical step clearer.

I built Vard CRM as a focused product for solo creative freelancers, starting from one real user rather than a broad imagined market. It is an AI build. Claude and Codex wrote essentially all the code, while I directed, decided and tested.

The core idea was simple. Status drives the work. Projects move through a clear pipeline, clients stay linked to the work, and the start page focuses on what needs attention next.

I deliberately kept the scope narrow.

• No multi-user agency workflows
• No complex forecasting
• No sales-team reporting
• No heavy permission model in the main product

This is what it does.

• A status pipeline from lead to paid
• Project and client records with linked history
• Next actions and recent activity on the start page
• Keyboard shortcuts for faster daily use, E to edit, Ctrl+S to save, Esc to cancel, and Tab through fields
• Preferences for language, startup page, theme, and checklist defaults
• Export support and audit logging
• A separate admin backoffice for user lifecycle, feature flags, maintenance banners, session controls, and security events

Because I am not a professional developer, I treated security as something to actively investigate rather than assume.

I used AI to map likely risks, then checked the repository with tools like Snyk and Aikido, reviewed Supabase RLS policies, kept privileged admin actions server-side, added audit logging, and separated admin concerns from the main product UI.

That does not replace a proper security review. It did make me more careful about the questions I ask, the assumptions I challenge, and the difference between a working product and something ready for wider use.

This project made the cost of product decisions very visible.

When AI lowers the cost of building, scope creep becomes easier. That made saying no more important, not less. It also made me appreciate how much judgement good developers bring to architecture, testing, maintainability, and security.

I also learned that AI-assisted building has its own kind of fatigue. It is exciting to write a spec, hand it to an AI tool, and see something working a few minutes later. That momentum can make it easy to keep going long after you should stop. Suddenly it is 04:00 and you have shipped five more ideas into the backlog. The work still needs judgement, rest, and a clear stopping point.

The most useful learning was that building something real for one person teaches more than building features for a vague market. It forced practical choices about what mattered, what could wait, and what would make the product safer to operate.