I wanted to feel excited about building again.
After 20 years in quality assurance, I started Quirence and began designing and building products with coding agents. Our first product is Rinkata. It grew out of a frustration I kept coming back to: working across ticketing systems and knowledge tools, while trying to keep agents focused on what I actually wanted to build.
My personal site gave me a chance to put that idea to work on something I cared about. I wanted it to show where I was going, how my QA background informed that direction, and why building had become interesting to me again.
My opening request was simple: I wanted a Tron theme.
That was the beginning of The Grid.
Giving the next chapter a shape
The first decisions were about the story. QA leadership belonged alongside my evolution into product design and building. Quirence and Rinkata gave that next chapter something concrete to point to. “Making building fun again” became the headline because it captured the motivation in my own words.
The visual direction developed around it: dark space, cyan light, a luminous disc, and a perspective floor. We worked through the typography, the page structure, and how much visual drama the opening should carry. The deeper reading pages needed a quieter treatment.
Small choices mattered too. I asked for the actual Rinkata logo from its website, then decided to remove it from the hero disc. It belonged in the product feature. The opening needed room for the wider personal story.
Those choices went into Rinkata’s Design Knowledge. It held the selected direction, the reasons behind it, and the details we still needed to resolve. That gave the agent something to return to as the conversation moved into implementation.
Making the work concrete
We chose Astro for the static site, TypeScript, and custom CSS for the visual system. Markdown suited how I wanted to write: work on a branch with an agent, inspect the rendered article, and review the change in GitHub. GitHub Actions ran the checks, and Vercel provided protected previews. The architecture and hosting choices went into Tech Stack Knowledge.
From there, we captured ideas in Rinkata and shaped them into a Goal, focused specs, and tickets. The foundation, homepage, blog, case study, discovery features, and quality work each had a defined place.
Before starting a ticket, the agent read its requirements and relevant Knowledge, checked readiness through Rinkata’s MCP tools, and claimed the work. Each slice then had something specific to implement and verify. Completion records included the code change, checks, and preview evidence, with findings written back into Knowledge.
The division of work was clear: I supplied direction and reviewed the result; the agent wrote and tested the code; GitHub held the implementation; Vercel served the previews. Rinkata held the project context, requirements, progress, and evidence.
That structure became especially useful when I changed the site architecture.
Story and Work needed more room
The original homepage had five sections: the opening, Work, Story, writing, and Contact. As the site took shape, I asked whether Story and Work should also have dedicated pages.
I wanted the homepage to give people a clear overview, with space to explore the career story and selected work in more depth.
That change touched more than two URLs. It affected the biography, project summaries, navigation, homepage links, metadata, and the journeys we needed to test.
Rinkata refused an attempted substantive rewrite of the original homepage spec because it already carried accepted evidence. We followed its guidance and created a successor spec for the new direction. Separate tickets covered Story, Work, and the navigation that connected them.
The original homepage work kept its evidence. The new pages developed their own content, and the navigation switched over once the destinations were ready. The original homepage section links continued to work.
This was a useful example of what I wanted from Rinkata: a change of mind could become explicit work, with its consequences carried through the build. It is also the concrete iteration described in the Rinkata case study.
Using information I had already supplied
Writing the Story page brought another part of the workflow into focus. When the agent asked for more career context, I pointed it back to my résumé in Rinkata.
The information was already there. Rereading it supplied evidence for the QA experience behind the narrative, while my newer account supplied the transition into Quirence and building Rinkata. I confirmed my public name and LinkedIn link as the copy developed.
That distinction mattered. An older résumé could support what I had done, but its employment labels could not establish what I was doing now. The writing needed to reflect the sources accurately.
The same care applied to the blog. We tested the article layout and publishing workflow with isolated sample content. The real site showed an honest empty state while no posts were ready. Having a designed article card did not make an article exist.
Bringing QA into the build
My QA background stayed part of the process. I wanted evidence that the site worked across the ways someone might actually use it.
We checked navigation, keyboard focus, mobile reading, touch, reduced motion, and essential behavior with JavaScript disabled. Browser coverage included Chromium, Firefox, and WebKit, alongside reviewed visual comparisons and accessibility checks.
One finding came from the decorative floor in the hero. Its perspective produced an excessively large projected area, and a Firefox accessibility scan timed out. Adjusting that geometry fixed the underlying problem. The dramatic opening still needed to behave well as part of a real page.
We also deliberately changed the built Work link to point at Blog. The existing visitor-journey test caught the wrong destination, and the original build was restored. That gave us evidence that the test could detect a meaningful mistake.
The full-site preview run before this post passed 19 content and configuration tests and 109 browser and visual cases. We also inspected reading and navigation manually and recorded performance measurements with their test conditions. Those results describe the build we checked; they are not a guarantee about every device or a substitute for every kind of accessibility review.
Keeping my direction in the process
There was friction. Older project context sometimes conflicted with the personal project we were using, and repeated approval prompts interrupted the flow. I had to make the intended project, the permission to continue, and the boundary around release explicit.
I eventually asked the agent to finish the remaining implementation and stop at a preview so I could review everything. That was the milestone this build reached. The final review and production release remained separate steps.
The experience made the human part of the work tangible. I kept deciding what the site should say, how it should feel, which details needed evidence, and when a change was ready. The agent helped turn those choices into something I could look at, use, and revise.
For me, that is the appeal of building this way. There is room to explore an idea, change its shape, and follow it into a working experience. Rinkata gave the decisions a place to live and a connection to the work that followed.
The Grid is a place to share more of that process: the designs, experiments, quality questions, and lessons that come from building.