Making PelAtlas Buildable: Structuring the Early Development of a Research Platform

In the past weeks I have worked a lot on PelAtlas. There is no new feature to point to yet. No interface that suddenly makes the system feel real. Instead, most of the time went into something less obvious: building a way of working that makes a project like this manageable in the first place.

PelAtlas is not a small script. It is a platform with many moving parts, and I am currently building it largely on my own. In that situation the first problem is rarely a technical one. The harder question is usually much simpler:

Where do I actually start?

Or even more importantly:

What is the next step?

When a project is still mostly an idea, it tends to appear as one large, blurry problem. Everything feels connected to everything else, and the entry point is unclear. Without structure it is surprisingly easy to spend time thinking about the system without actually moving it forward.

Turning fog into steps

To deal with that, I returned to something very conventional: the planning structure I had used for years in software development.

Milestones -> Epics -> Stories

The idea is simple: take something that looks like a platform-sized problem and keep cutting it into smaller pieces until the remaining unit is something you can actually sit down and work on.

To help with that decomposition I built a small GPT tool for myself — the Task Decomposer. Its only purpose is to help slice larger goals into milestones, epics, and finally concrete stories.

From there I set up three linked databases in Notion and built a classic Kanban board around the story level.

None of this is perfect. Some tasks are probably still too large, others might be split in the wrong place. And new work will inevitably appear once implementation progresses.

But the value of this structure is not perfection.

Its value is that it creates continuity. Instead of facing a large and undefined system, I always have something concrete that can be done next.

And there is another small but surprisingly powerful effect: things can actually become done. Checking off a story is not a big milestone for the platform, but it creates a steady sense of progress — something that matters a lot when building a system that will take a long time to emerge.

Working with coding agents without losing control

The second question I had to answer for myself was how to use AI in the implementation process.

It was clear from the beginning that I would rely on a coding agent — in my case opencode . But simply delegating code generation was not the goal. What I needed instead was a process that allowed me to benefit from automation while still keeping a clear understanding of the system.

So I started defining a small set of roles.

For planning I use an agent I call Architect, together with the excellent plannotator plugin. That phase is mostly iterative: discussing a feature, revising the idea, pushing back on the plan, and gradually refining it until the structure makes sense.

Only then does code generation enter the picture.

Implementation is handled by a dedicated TDD agent, which produces both the code and a small piece of documentation explaining the feature or process that was introduced.

From there the workflow becomes deliberately human again. I test the changes and create a pull request in GitHub. I then review that pull request carefully - including writing review comments to myself and answering them before merging.

It may look slightly absurd to review your own pull request, but the step serves an important purpose: it forces one more structured pass over the changes and helps ensure that the implementation still matches the original idea.

Building the form before the system

I do not yet know whether this process will prove efficient.

The coming weeks will likely reveal weak points. Some steps might turn out to be unnecessary. Others might need refinement.

But the process already achieved something important: it gave the project a form.

Not the form of a finished platform - that will take much longer - but the form of a workflow in which complexity, next steps, and responsibility remain manageable.

In other words, PelAtlas is not fully built yet.

But it has become buildable.