Findy, the build method

Two maps of the same build

You described the order you thought we were working in. The method has its own order, written down in three places and never drawn anywhere. Here they are side by side, with the six points where they part, and a mark showing where Findy actually sits today.

Read from the method library, 1 September 2026 Checked against the 58 command files installed in this project Your order is your own words, not a paraphrase
Map one

The order the method actually runs in

Ten stages. The first four happen once for the whole project. Everything after that repeats, once for each slice of the app, and Findy has fifteen slices listed. A filled dot means it is done. A hollow red dot means it has never run here.

Once, for the whole project
0 Set up the folder Done

A setup script, typed into the terminal rather than to me. It creates the project folder and puts the first nine commands in it.

1 Ask where you are /implementation-guide

Reads the project's own files, works out which stage you are standing in, and names the one thing to run next. It changes nothing. It can be run at any moment, and this is the command your second point is really about.

Run for the first time ever on this project on 1 September 2026, six sessions into the design work.

2 Write the constitution /spec-writer Done

Produces SPECS.md, the document that wins every argument, plus the short lookup version of it. Two things are still owed here: a whole-document review pass and your signature on it.

3 Build the scaffolding /bootstrap-project Done

Writes the rulebook every session reads, the state files, the design folder, the menu of fifteen slices, and installs the other forty-nine commands.

Findy is standing here

The project's own stage check returns spec-written: the constitution exists and not one slice has been written up. The features folder holds a single menu file and no slice folders at all, so every stage below this line has never happened.

The week of screens and icons sits beside this map rather than on it. That is the whole finding, in one sentence.

Then repeated, once per slice of the app, fifteen times over
3.5 Surface the unanswered questions /pre-pack-architectural-surface Never run

Walks the slice and everything it depends on, finds every decision nobody has made yet, and puts them to you. The next step refuses to start without its receipt, and that refusal is deliberate: without it, the plan gets written on decisions you were never asked about.

4 Plan the slice /feature-plan Never run

Writes four files for that slice: what it does, the shapes the data takes, every state each of its screens can be in (loading, empty, no signal, gone wrong), and how you know it passed. Those states are the thing screen designs need and cannot invent.

5 Design, six steps ending at one stamp Never run

This is the stage the last week of work belongs to, and none of its six steps has run.

  • 5.1Record the design tool /design-platform Says which tool draws the screens. Findy's record still names the one you parked on 31 August, and it now fails to connect. Every design command reads that record, so the whole stage currently points at a dead route.
  • 5.2Push your taste into that tool /design-system-push Puts your colours, lettering and motion into the tool before its first drawing. Skip it and the tool applies its own defaults, and you meet them as finished screens.
  • 5.3List every screen /screen-inventory Findy has this one: 95 screens are listed. It was written by hand rather than by the command, but it exists.
  • 5.4The wireframes /screen-inventory --flow Every screen drawn as grey blocks carrying the real words, with an arrow off every tappable thing showing where it goes. This is the method's wireframe step, and it sits here, before anything is styled. It is also the first moment the app can be seen rather than read as a list.
  • 5.5Draw the screens The design tool's own step, whichever tool the record at 5.1 names.
  • 5.6Check the designs /design-check The gate Reads the designs against the list and writes one report. That report saying PASS is the single stamp that lets anybody write a line of code, and three separate later commands refuse without it. Findy has no report at all.
6 Plan the build /build-pack Never run

Turns the slice into numbered phases and stops. It writes no code. Two companions size the work and find what can run at the same time.

6.5 Prepare each visual phase, in this order Never run
  • Decide what has to move /animate Its second step is titled, in the file itself, "what must move, decided before any artwork exists". This is the half of your point five that runs early.
  • Enrich the phase and list what art it needs /design-preflight Its required input is the build plan from stage 6, so it cannot run before a slice has been planned.
  • Make the art /asset-forge Runs only when the step above flagged something missing. This is the command you have been asking about, and this is where the method puts it.
7 Build it /build-team Never run

A guide and a builder work the phases. Between phases there is a loop of its own: check the code against the design system, propose fixes, apply them, then you hold the phone and say whether it feels right.

8 Review the slice, all eight steps Never run

Six review commands and two scripts read the code. The eighth opens the running app, and it is the only one that does. The first seven all come back clean on a build that launches to a blank screen.

9 Close, then start the next slice /close

Files what was learned, updates the bookmark files, commits and pushes. Then the route returns to 3.5 with the next slice. This is the only stage of the loop that has ever run on Findy, and it has run every session.

Once, at the very end
10 Release Never run

Two blocking gates before anybody outside the house touches it: a safety floor for the app itself, and an app store readiness pass for Apple and Google. A third gate, a safety check on this Mac, has also never run and only you can run it.

What the method says about starting a session

In its own words: nothing starts a session, you read what the last one left. There is no start command, and there never was. That is a deliberate choice, it is written into the guide command's own list of names that do not exist, and it is the thing your second point objects to.

That was true when this page was first drawn and it stopped being true the same evening. This project's session-start check now states the stage and routes to the guide every time, so on this one point the project and the method library now disagree, and the project is the one that is right. See point six below.

The gap

What sits beside the map rather than on it

None of this is wasted and none of it is wrong. It is simply not recorded anywhere the method can see, so every gate downstream reads the project as having produced nothing.

  • Screens listed in the inventory95
  • Screens the pipeline's own register records as designed0
  • Screens drawn by hand in the explorations folder9
  • Icons drawn, registered and checked39
  • Slices of the app listed on the menu15
  • Slices with a spec, contracts, states or acceptance file0
  • Commands installed in this project58
  • Design commands run in the last six sessions0

The explorations folder says so itself: not one of those nine screens is a screen anybody can reach. They are for settling taste, and they settled it. The register the pipeline reads holds zero rows and says, in its own body, that no design has been produced for any screen. Both statements are true at once, which is exactly why nothing flagged it.

Map two

The order you described

Drawn from what you dictated on 1 September, kept in your sequence and your emphasis. Two further statements you made sit underneath it, because they are about the method rather than about the order.

1The specs

Same as the method, same place. No disagreement.

2The screen inventory

The list of every screen. Same as the method's step 5.3, and you were right that it comes early.

3Agree the order of screens, and what happens when you click each thing

This is, almost word for word, what the method's wireframe step produces. You put it third. The method puts it fourth of six. You are within one step of each other here.

4Start creating the screen designs
5Discover the inventory needs changing, and tweak it

The method agrees with this explicitly. The inventory is written down as a suggestion list rather than a fixed one, and items can be dropped, merged or reworded as design goes on.

6Arrive at a final list of screens
7Create the wireframes

This is the first real parting. See point one below.

8Build the screens up in segments and sections, in more and more detail, until they are final
9Along the way, discover which assets are needed

Images, icons, graphics, motions, in your words.

Second parting. See point three.

10Once everything is placed and drawn, work out where the animations, motion and sound go

Third parting, and the smallest one. See point four.

11Then build

Every screen designed, and a library of every image, sound and animation in hand, before a line of the app is written.

Fourth parting, and the biggest. See point two.

And two statements about the method itself

One. At the start of every session a command should be invoked, and the right one for the stage we are actually at. Point six.

Two. You do not recognise the idea of a feature pack, and you asked openly whether it is complexity we no longer need. Point five, and it is the one with the most riding on it.

The delta

Six places where the two maps part

Each one says what you have, what the method has, and which of the two I think is right after checking it against the command files rather than against my memory. Two go to the method, two go to you, one is not a real disagreement, and one is a genuine question only you can answer.

Point oneWhen the wireframes get made

Your order

Design the screens, settle the list, then wireframe. Wireframes come after the look is worked out.

The method

Wireframes come before anything is styled: every screen as grey blocks with the real words in them and an arrow off every tappable thing. The design tool's own wireframe mode then reads that file as its input rather than producing it.

The method is right here

Its reason is one you would give yourself: at that moment a change costs almost nothing, and it is the first point where the app can be looked at rather than read as a list.

But the method also admits the trap you walked into. Its own file says no later step refuses to proceed without a locked flow, so if you reach screen design without one, nothing stops you and screens get produced with no agreed structure behind them. That is what happened, nine screens ago.

What your order costs: a look settled on a structure nobody agreed, then a screen moves and the look gets drawn again.

Point twoWhole app first, or one slice at a time

Your order

Design all 95 screens, gather every image and sound, and only then start building.

The method

Design and build one slice at a time, looping stages 3.5 to 9 fifteen times, so screens are drawn in slice-sized batches with building in between.

You are half right, and the method already agrees with that half

There is a mode built for exactly your instinct: a coverage pass that lists every screen the app needs so design is not blocked while the slices are still being planned. Findy has already had it, by hand: that is where the 95 comes from.

What cannot be done up front is each screen's states, the loading, empty, no signal and gone wrong versions. Those are written by the planning step for a slice. Design a screen before them and you either guess the states or leave them out, and the design check will find the gap later.

What your order costs: some screens get drawn twice. The list can be whole app. The finished screens cannot, unless we accept the redraws.

Point threeWhen you find out what art you need

Your order

The list of images, icons and graphics emerges while you are designing screens, which is when you can see what is missing.

The method

The art command runs only when the phase preparation flags something missing, and that preparation cannot run until a slice has a build plan. So art sits a long way downstream of where you expect it.

The method is right on paper and it has a real hole

Its ordering is sound for art that goes into a built screen. But there is no step anywhere in it for art you need in order to settle taste before any slice exists, and that is precisely the thing you needed. Thirty-nine icons got drawn last week for that reason, and the method has no place to put them.

This is worth writing back into the method rather than working around again.

What it costs either way: nothing yet. The icons are drawn, they are registered, and they are checked. The cost lands the next time we need art and there is still no planned slice to hang it on.

Point fourMotion and sound at the end

Your order

Once everything is placed and drawn, work out where the animations, the motion and the sound effects go.

The method

The decision about what has to move comes before the artwork is made. The animate command's own second step is titled "what must move, decided before any artwork exists", and it says in the file that it must run before the art command so that what gets drawn contains the parts that have to move.

Not really a disagreement, and nobody has said so to you before

You are right that the built animation is last. The method agrees. What it puts first is only the decision, because a flat picture cannot be taken apart afterwards: if a drawer has to open, somebody has to paint the inside of it before the drawer is drawn shut.

This has already paid off once here. The pin board idea produced a rule, that the board has to be drawn complete behind where the photograph lands, and finding that after the art was made would have meant drawing it again.

What the confusion costs: one wasted round of artwork per thing that turns out to move.

Point fiveWhether slices of the app are a thing we need at all

Your question

You said you are not familiar with the idea, that you are getting lost there, and that it may be complexity that was needed once and is not needed now. You called it an open question.

What one actually is

A slice of the app that gets specced, designed, built and reviewed as a unit before the next one starts. Findy has fifteen listed, from the foundations, through Containers, photograph capture, search and the kitchen, to export.

Genuinely open, and it is yours to answer

Six of the ten stages loop once per slice, so this single question changes the shape of everything below stage three. It is the largest lever on this page.

What they buy: each screen gets drawn against real states rather than guessed ones, the build arrives in pieces you can look at, and a mistake is contained inside one slice. What they cost: you cannot have the whole app designed to a finished standard before any of it is built, because the states each screen needs are written slice by slice.

If we drop them: the method's whole build half loses its unit, and the eight review steps, the design gate and the architecture questions all lose the thing they are scoped to. That is not a reason to keep them. It is the size of the change.

Point sixWhether something should run at the start of every session

Your position

At the start of every session a command should be invoked, and the right one for the stage we are actually at. It is clearly not happening.

The method

Says the opposite, in writing. Under the names it says do not exist, next to start, begin and kickoff, it reads: nothing starts a session, you read what the last one left.

You are right, and this is the one that caused everything else

Six sessions ran with all 58 commands installed and not one design command reached. Every handover opened by naming the next task, and not one of them asked what stage the project was at. Working out the stage costs a single command and it is the only thing that would have caught this.

On your other assumption, that the map was never loaded to me: you are right about the mechanism. The order exists as prose in a guide chapter and as a block of text inside a large command file. It is in no file a session reads automatically, so unless that one command is invoked, neither of us ever sees it. That is a fact about where the method keeps its own order, and it is the reason this page exists.

Fixed on the evening of 1 September, after this page was first drawn. The check that runs at the start of every session now states the stage and names the guide, and the closing note takes its first action from the same derivation rather than from memory. A live map of the position, redrawn by the guide each time it answers, now sits at a stable address that does not depend on which account is signed in.

What it cost to fix: two small changes to files that already existed, and it is mechanical rather than a habit either of us has to remember.

What this page is not

It is not a decision. Nothing here changes the project, no file has been moved, and the design tool record still names the parked tool. Four of the six points are settled by reading the method's own files. Two are yours.

It is also not a picture of Findy. The one sheet of screens is still the comparison sheet in the explorations folder, and this page deliberately does not go near it.