Running this site as a project

Situation

My CV tells you what I did. This site shows my way of thinking.

There was another reason for building it. In my previous role I used Jira and Confluence the way most delivery people do - raising tickets, tracking progress, reading documentation someone else had written. I’d never set up a board, defined a workflow, or owned a space from the first page. This was a chance to work from the other side of those tools: to build the structure rather than operate inside one.

So I gave myself a real project. Not a mock-up or a course exercise - something with a scope I had to define, decisions I had to make and record, and a deliverable that would be public.

I’m not a developer. AI wrote the code. But every decision about what the site should be, what went in it, what got cut and when it was finished was mine, and that turned out to be the harder half of the work.

Constraints

Budget: the domain and nothing else. No developer, no paid tools, no template I would have had to pay for.

No coding experience. I’d never written a line of production code, and I’d never used AI to write any either. Everything about how to work with it, I worked out on this project.

Time. Built alongside a job search, in whatever hours were left over.

What I did

1. Set up the project and the flow it ran through. Requirements were written as user stories with acceptance criteria, then loaded into Jira as a backlog. Epics were broken into stories and sub-tasks, estimated, prioritised, and pulled into short sprints against a sprint goal. I designed the workflow the board ran on rather than taking a default: To Do, In Progress, In Review, Done, with Blocked reachable from either active state so stalled work was visible on the board instead of sitting silently In Progress.

   

   

   

   

2. Documented it to the standard of a client engagement. A project charter, a RAID log, requirements, definitions of ready and done, a decision log and an action log, all held in Confluence alongside the sprint and reporting pages. Each decision was recorded as its own page with the options considered and the rationale behind the choice, not only the outcome, so a decision could later be reviewed on the record rather than reconstructed from memory.

   

3. Used AI as the build resource, working to requirements and acceptance criteria. I set the priorities and wrote each item as a requirement with its acceptance criteria; Claude implemented against them. I then tested each delivery in the browser against those same criteria before accepting it. Where something did not meet them, a Bug in Jira was raised to resolve the ambiguity.

   

   

   

   

   

   

   

Result

What started as a way to practise some tools ended up as the thing you’re reading.

The site does what it needed to: the professional work, the photography and the painting in one place, and these case studies as the evidence behind the CV.

The more useful outcome was the practice. I now know what it takes to set up a board and a workflow from nothing, keep a decision log that’s worth reading later, and run iterations short enough that something works at the end of each one. I’d used those tools for years without ever building the structure they sit in.

The code was the fast part. Deciding what the site should do, judging whether what came back was right, and calling it finished - that took the time.