The build journal

From day one.
Still building.

A chronological record of how a small ideation experiment is becoming an AI-native platform — including the foundations and changes of ambition that made the next step possible.

31documented
build days
01 The story so far
01
Day one

From a blank repository to a working ideas product

The first version established the basic loop: capture ideas, develop them with AI, compare possibilities and turn the strongest thinking into a roadmap.

  • Created the application and API structure
  • Built ideas, comparison and roadmap experiences
  • Connected generated API clients
  • Explored early visual directions
The decision was to build the whole learning loop, not just another suggestion box.
02
Day two

Making comparison useful, not just interesting

The focus moved to evidence and decisions: stronger comparison flows, relationship data and results that could leave the system as a useful CSV.

  • Expanded the comparison engine
  • Added CSV export from results
  • Introduced record relationships
  • Regenerated schemas and API clients
A product becomes more credible when users can take the result away and do something with it.
03
Day three

Context, agents and the first real architecture

The ideas tool started becoming a platform. Agents gained clearer responsibilities, comparisons became transitive and context could travel with ideas.

  • Refined chief and ideation agents
  • Added context management
  • Protected graphs from circular failures
  • Documented the architecture and migration
The project stopped looking like one feature and started looking like a system.
04
Measuring the machines

Making AI usage visible

The platform began recording model consumption and exposing usage to administrators.

  • Added AI usage events
  • Captured Anthropic consumption
  • Created usage APIs
  • Extended administration views
Autonomy without measurement is a creative way to lose control of a budget.
05
Organising access

From individual users to real organisations

The system gained organisation membership, audit events and a more repeatable deployment model.

  • Built organisation access
  • Added audit events
  • Expanded workspace navigation
  • Hardened Docker deployment
The platform must know who you are and which hat you are wearing.
06
Richer records

Profiles, attributes and fields that fit the work

Profiles, custom attributes and numeric fields made the model less rigid.

  • Added user profiles
  • Created custom attributes
  • Added numeric inputs
  • Connected profile context
Not everybody’s data looks exactly like yours.
07
Guardrails

Stopping accidental work from disappearing

Editing flows gained draft states and warnings before unfinished changes were discarded.

  • Added unsaved-change guards
  • Connected navigation warnings
  • Clarified save behaviour
  • Made drafts explicit
A tiny warning can save a large amount of inventive vocabulary.
08
Showing the answer

A reusable visualisation layer

A shared presentation model separated the meaning of data from how it was displayed.

  • Created a visualisation library
  • Defined presentation controls
  • Separated data from output
  • Prepared reusable views
The best visualisation makes a complicated relationship obvious.
09
Making views recognisable

Presentation became part of the model

Presentation language and icon treatment made configurable views feel deliberate.

  • Added presentation iconography
  • Aligned view types
  • Improved output cues
  • Prepared multiple modes
Configurable does not have to mean visually anonymous.
10
Context everywhere

Records learned how to explain themselves

Generic headings, formatting and relationship panels gave every object consistent context.

  • Built relationship panels
  • Added context headings
  • Centralised formatting
  • Reduced idea-specific code
A record’s relationships are usually where the story lives.
11
The model editor

Letting the platform describe new products

Model services and drag-and-drop editors replaced more hard-coded ideation behaviour.

  • Added metadata services
  • Built designer foundations
  • Created shared model hooks
  • Refined agent roles
The platform began learning how to assemble an answer.
12
Work that comes back

Workflow notifications arrived

Scheduled notifications made approvals and outstanding work visible and actionable.

  • Created notification scheduling
  • Added notification APIs
  • Built the notification workspace
  • Connected workflow states
A quiet workflow is often not finished; it is merely lost.
13
The platform turn

Replacing fixed screens with configurable building blocks

Objects, fields, collections, relationships and visualisations became reusable platform capabilities rather than code tied to ideas alone.

  • Created metadata-driven object models
  • Built design-system foundations
  • Added organisation and workspace concepts
  • Introduced configurable views
The ambition changed from building one app to building the machinery that can create many useful apps.
14
Designing the work

Views, workflows and a platform people can shape

Page designers, view builders, workflow approvals, notifications and administration moved into the product itself.

  • Built page and view designers
  • Added workflows and approvals
  • Introduced platform blueprints
  • Expanded user and usage administration
Configuration only becomes a product when it is understandable, previewable and safe to change.
15
Today’s direction

Building the organisation that builds the platform

User requests can enter a structured queue and specialist agents can investigate, plan, build and test changes inside a controlled environment.

  • Added scheduled Codex work
  • Separated agent responsibilities
  • Introduced controlled approvals
  • Connected demand to enhancement work
The goal is an organisation of agents with clear jobs, bounded authority and evidence at every hand-off.
16
Opening the workshop

Giving the work a public home — and a safe route back to it

Product Agility gained its public story, a more balanced visual identity and an approval-gated publishing loop that can turn each day’s work into a useful Build Notes update.

  • Created responsive .co.uk and .app holding sites
  • Rebalanced the logo and tuned the branded Poppins typography
  • Put an AI-scheduled daily Build Notes agent live and completed its first scheduled review
  • Published through isolated FTPS with explicit approval required for every release
Automation becomes useful when it knows not only how to publish, but when to stop and ask.
17
Teaching the platform to design

From a one-line idea to a governed blueprint

The Platform Builder learned to turn a short product brief into a compact, reviewable application blueprint — complete with objects, views, relationships and the gaps worth feeding back into the improvement loop.

  • Added AI-assisted brief expansion and blueprint drafting
  • Made generated views, including relationship networks, previewable before they are applied
  • Added validation, reusable templates, sample data and guarded recovery
  • Routed reusable capability gaps into a private Platform Improvement Lab for review
The useful trick is not asking AI to invent a whole product. It is giving it a bounded design job, then making every assumption visible.
18
Giving diagrams a language

Shapes, connectors and meaning — without locking the platform to a notation

The workspace engine gained a shared visual language for diagrams, so people, processes, products, data and architecture can be modelled clearly while the meaning remains portable underneath.

  • Added original shape libraries for everyday work, product, data, organisation, architecture, requirements, ideation and process modelling
  • Separated an object’s semantic type from its chosen shape and presentation icon
  • Translated relationship and cardinality metadata into arrows, diamonds and crow’s-foot connectors
  • Added searchable, scoped shape pickers and editable network diagrams with staged saves
A diagram becomes much more useful when its shapes are not just decoration, but a readable view of the model underneath.
19
Turning the model into a workspace

A process-modelling product built from the platform itself

The generic workspace engine was used to assemble a working process-modelling product, joining a searchable catalogue to record-backed diagrams that can be shaped without creating a separate application stack.

  • Created a reusable workspace blueprint for processes, activities, events and gateways
  • Added a diagram catalogue and a focused canvas for opening one model at a time
  • Enabled drag-and-drop creation or reuse of existing model elements
  • Added floating connectors, record and relationship inspectors, and guarded staged saves
The best proof of a platform is not another platform feature; it is a useful product assembled from the parts already there.
20
Making diagrams behave

From drawing shapes to configuring how work appears

Diagramming moved beyond a fixed canvas: object types gained native or card presentation, configurable icon placement and dedicated inspectors, while conditional forms learned to respond to the record in front of them.

  • Added native and card symbol modes with shape-appropriate proportions
  • Made node size, rotation and icon placement configurable and persistent
  • Added dedicated diagram-inspector forms and conditional field rules
  • Gave both public sites a clean branded browser-tab icon
Visual flexibility is useful when it is still driven by the model, rather than becoming a collection of one-off decoration.
21
From words to diagrams

Letting AI draw inside the rules

The platform gained a permissioned diagram generator that turns a plain-English request into a small, editable model using only the objects, connectors and published diagram types the user is allowed to access.

  • Created a shared catalogue for consistent process-event, activity and gateway notation
  • Added an AI Diagram Generator capability granted per workspace member
  • Constrained one cost-capped model call to allow-listed metadata without sending existing records
  • Used deterministic APIs to save records, relationships and geometry while metering usage
AI becomes easier to trust when it can be creative only inside a vocabulary and permission boundary the platform already understands.
22
Putting work in its place

Pools, lanes and rules that make a process readable

Process diagrams learned about responsibility as well as flow: participants can own lanes, lanes can contain work, and the canvas now protects the difference between a sequence inside a participant and a message crossing between them.

  • Added participant pools and nested responsibility lanes
  • Made containment structural rather than drawing it as another connector
  • Kept sequence flows inside participants and reserved message flows for crossing between them
  • Added canvas controls for creating and removing lanes while preserving the underlying records
A useful process model does more than show what happens next; it makes clear who is responsible when it does.
23
Tidying the canvas

Giving a complicated diagram some manners

The process canvas became a more practical place to work: layouts can be arranged, adjusted and reversed without losing the structure that makes pools, lanes and flows meaningful.

  • Added container-aware automatic arrangement with compact, balanced and spacious options
  • Introduced undo and redo for layout changes
  • Added multi-selection, alignment, distribution and position locking
  • Made process validation and unsaved changes clearer while editing
Automation is most useful when it does the tidying, but still lets you move the furniture afterwards.
24
Testing the whole journey

Giving the platform a customer with a clipboard

A repeatable customer-experience QA run tested the platform as real administrators and members would use it, carrying synthetic work through architecture, ideation, comparisons, diagrams and AI rather than checking each feature in isolation.

  • Ran 17 recorded customer journeys across Enterprise Architecture and Ideation workspaces
  • Created realistic synthetic records, relationships, comparisons and diagrams, then checked that saved work survived refresh and reopening
  • Captured a local evidence library with 20 screenshots and linked results back to a dedicated QA workspace
  • Turned failures into six traceable findings, including missing relationship controls and unreliable AI responses
A platform can pass every small technical check and still trip over the customer’s actual day. The clipboard is there to keep us honest.
25
Moving the workshop

Moving the workshop without losing the tools

The platform moved to a new machine with its existing application images, data and history intact. The less glamorous work was making sure it could come back after a restart — and that the people-shaped agent crew still knew which jobs belonged to them.

  • Moved the existing Docker application and database to the new machine, preserving the original source and handover history
  • Extended backups to cover the migrated database and tested restoring them separately
  • Checked restart recovery, with a successful database backup while the machine was still at the sign-in screen
  • Restored the crew’s responsibilities and dedicated work areas, with a private dashboard that distinguishes recorded schedules from live activity
  • Rebuilt the website locally and identified missing release material before attempting another public update
Moving a workshop is a useful test: the tools are only half the story. The labels, instructions and spare keys matter rather more than you expect.
26
Checking the labels

Making done mean done

Today was about the gap between work being prepared and work actually being finished. The crew gained a clearer record of outcomes, while the website release needed a little detective work before it could safely leave the workshop.

  • Captured two new ideas as verified drafts, while leaving older completion claims unchanged where the workspace had no supported completion state
  • Added an Operations view to the private crew dashboard, keeping source results and recorded schedules separate
  • Recovered the existing privacy page and checked that its exact contents matched the public site
  • Verified website access in my Windows session and prepared a two-page release operation that checks the live baseline and stops if a backup fails
A tick is a small thing to draw and a surprisingly large thing to justify. I’m learning to keep the evidence beside it.
27
Giving the crew a workbench

A place for the work, not just the names

The crew has had names and responsibilities for a while. Today it gained more practical places to put the work: website changes, releases and marketing activity now have their own installed workspaces. The less photogenic progress was making the handovers clearer.

  • Verified the website and marketing workspaces built from reusable blueprints, keeping their empty registers honest rather than filling them with pretend progress
  • Put engineering intake and recorded outcomes under Apollo, with independent testing handed to Hubble
  • Independent testing found two approval edge cases; the fixes passed a bounded retest, while live integration remains to be checked
  • Brought a real source report into the private dashboard once, then checked that reading it again did not create another result
A name on a door is a start. A useful workbench, a clear handover and someone willing to check the result make it a place where work can actually happen.
28
Leaving room to finish

Knowing when to stop is part of the job

Today the crew gained a less glamorous kind of capability: a clearer idea of when to stop. Vega now has a place in the dashboard and a remit to keep capacity visible. The harder work was turning a sensible reserve policy into checks that the dispatcher can actually use.

  • Added capacity checks before the dispatcher admits work and starts another stage, while leaving room for safe cleanup
  • Independent testing found two edge cases; the corrected source passed its retest, followed by a separately reviewed activation
  • Fixed a dashboard refresh bug that left the new crew member out of one view, and made paused jobs unmistakably paused
  • Kept the limits visible: activation evidence is not a live-work test, and these guards cannot cap every use of a shared account
A system that can start another task is useful. A system that knows when to leave enough room to finish the current one is beginning to show better judgement.
29
Counting with care

Giving the numbers a little context

The crew gained a usage history view today: a way to see where the recorded work went, with dates, models and tasks to explore. The useful part was not the biggest number. It was making clear what the numbers could—and could not—tell us.

  • Added a private usage history view with daily totals, filters and task drilldown
  • Kept cached input separate and missing history visible, without turning token counts into a pretend bill
  • Independent checks caught two date-handling edge cases; both were corrected and the evidence stored
  • Recovered the public publishing route and verified the two previously approved Build Notes entries online
A dashboard should help us ask better questions. A large number without its context mostly helps us raise an eyebrow.
30
Knowing when to pause

A little room to stop well

Today was about deciding when the automated workshop should ease off. We clarified the difference between an early warning, a pause on new work and a final reserve, then checked that the dispatcher had picked up the change. Small rules, but useful ones when enthusiasm is easier to find than spare capacity.

  • Separated the dispatcher’s final reserve floor from its earlier warning and pause thresholds
  • Checked the boundary cases independently and saved the source review evidence
  • Verified the updated runner restarted idle, with matching source files and no work taken on for the check
  • Kept the limits explicit: this guards the dispatcher, not every use of the account
A useful guardrail should know when to say “steady on” and when to put the kettle on.
31
A closer look first

Looking before letting go

The record-collection app became a little more useful today: tracks can be edited, artists can share a credit, and imported details can be checked before they are kept. Alongside it, a small maintenance tool learned to review proposed changes without applying them. The common thread was giving ourselves a proper look before pressing on.

  • Added track editing, multiple artist credits and selective imports of release details
  • Kept imported information traceable and older backups readable
  • Corrected issues found in independent reviews of the metadata importer and maintenance checks
  • Deployed the supporting metadata service, with real sign-in and end-to-end checks still to complete before the app goes public
“Let me have a look first” is a perfectly respectable feature.
02 What comes next

The notes continue as
the platform learns.

New entries will follow the work: what changed, why it mattered and what it taught me about building products with agents.

Visit the platform holding page ↗