Vard CRM, a small CRM for one 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 the way he works. A status pipeline, linked clients, and a start page of next actions.

What it was worth

Finished and never used. He got a job first. The lessons about scope, and about building with AI, stayed.

The call

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

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

He did not need a sales CRM. He needed a calmer way to keep track of clients, projects, status and the next action on each, without the features an agency would want.

The name comes from the Nordic varde, a stone cairn that marks the way for whoever comes next. That felt right for a small CRM whose job is to make the next practical step obvious.

I built it for one real user rather than an imagined market of freelancers. Claude and Codex wrote essentially all the code. I directed, decided and tested. It was my first build with a frontend, a backend and a database, and before it I had made prototypes, not products.

Status drives everything. A project moves through a pipeline, the client stays attached to the work, and the start page shows what needs attention next.

The scope stayed narrow on purpose.

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

• 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 daily use, E to edit, Ctrl+S to save, Esc to cancel and Tab through the fields
• Preferences for language, start page, theme and checklist defaults
• Export and an audit log
• A separate admin backoffice for user lifecycle, feature flags, maintenance banners, session controls and security events

I am not a developer, so I treated security as something to go and check rather than assume.

I used AI to map the likely risks, ran Snyk and Aikido over the repository, reviewed the Supabase row level security policies, kept privileged admin actions on the server, added audit logging and moved the admin concerns out of the main product.

None of that replaces a proper security review. It did change the questions I ask, and it made the gap between a working product and one ready for other people very concrete.

This project made the cost of product decisions visible.

When AI makes building cheap, the mistakes move from making it work to choosing what to make, and saying no matters more, not less. The Archive Lens decision log shows that over four months, entry by entry. It also gave me a sharper respect for the judgement developers bring to architecture, testing, maintainability and security.

Building with AI has its own kind of fatigue too. Write a spec, hand it over, and something works a few minutes later. That momentum makes it easy to keep going long after you should have stopped, until it is 04:00 and five more ideas have gone into the backlog. The work still needs judgement and a clear stopping point, and a night's sleep.

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