start with
what matters.

understand the work.

i start with the outcome and work backwards. what needs to happen? what information is needed? where does a person need to make a decision?

inside a company, that means understanding the people, the systems they already use, and the exceptions that never made it into a process document. the way work actually happens matters more than the diagram.

before i automate anything, i ask whether it needs to happen at all. a process can exist simply to keep another process moving. making it faster is only useful if the work still matters.

ask less of the person.

i want to work through the email, calendars and systems people already use. no extra dashboard to remember. no new routine just to keep the software informed.

that takes an understanding of the organisation: its people, permissions, information, decisions and exceptions. the architecture should carry the coordination quietly, and bring someone in with the context they need when judgement is required.

unterlagen. prepare the decision.

an incoming email becomes work for the system. unterlagen reads the request, finds the records, checks the facts and prepares the complete response to the organisation’s exact instructions.

the person receives the finished reply, every required attachment and the evidence supporting it. the original request has already been dealt with. there is no searching for an order, assembling documents or starting a draft.

what remains is one decision: approve, edit or reject. the example on this site brings a reply about a delivery date together with the order and shipping confirmations, and the records that verify the date.

i keep that evidence visible and that choice with the person. a delivery date may be correct while the reply still needs a little care. the preparation is complete; responsibility stays human.

follow it all the way through.

i work across design, architecture and development. how something feels is connected to how it is built, and both are connected to the problem it is meant to solve.

i use ai throughout that process, from exploring an idea to writing and reviewing code. it helps me move between the parts, but the choices and the responsibility remain mine.

make responsibility clear.

ai can interpret. rules can calculate. people decide. each part needs a clear job.

truhe makes the distinction tangible. its offline app reads pdfs and electronic invoices on the device, calculates the covered electricity, gas and heating-oil refunds, and generates the complete filing documents there. the person receives completed filing templates, calculations, supporting records and submission steps in one package.

i chose explicit, reproducible rules for the calculation and local processing for the bills. uncertainty remains visible for confirmation. the person or tax advisor checks the result and submits it; the app does the reading, calculation and preparation.

calculate the system together.

luw’s engine models solar, batteries, cars and thermal storage within one energy balance. it compares plans against physical limits, charging needs, comfort, battery losses and wear. those constraints belong in the calculation together.

the current homey beta discovers measured storage, car charging and flexible loads, then compares their use with alternative schedules. its assessment shows the estimated saving, price assumptions, evidence and excluded devices. it changes no devices.

finish the handoff.

staedy takes an unanswered guest question through to the website change that answers it. the result is complete pages, copy or code, with source evidence, exact placement and the checks needed to implement it within the hotel’s existing site.

the handoff needs to be usable. finished files, a clear implementation brief and a preview for approval. the example here uses fictional hotel details, but its html and css are complete and downloadable.

build a little. learn a little.

i make a working version, test the assumptions behind it, and refine what does not hold up. i check the parts together, because a good interface cannot compensate for a system that gets the answer wrong.

then i keep paying attention. does this help? is it understandable? did it take something off someone's plate, or quietly add another thing?

those are the questions i want the work on this site to answer.