Da vi begynte å skissere et App Studio for IntentForce, var det fristende å starte med rammeverk, byggkjeder og appbutikker. Jeg valgte å begynne et annet sted: med telefonen kunden faktisk skal holde i hånden, og den ene reisen appen først må gjøre forståelig.
Resultatet er en klikkbar nettleserprototype der iPhone- og Android-visning, skjermstørrelse, retning og fargetema kan prøves før vi låser den dyre delen av utviklingen.
En prototype gir samtalen et felles sentrum
En tegning kan forklare hvor en knapp kanskje skal ligge. En livevisning lar kunden trykke på den og kjenne om flyten gir mening. Det er en viktig forskjell. Når både kunde og utvikler ser samme versjon, blir tilbakemeldinger konkrete: «denne handlingen må komme tidligere», «ordet passer ikke målgruppen» eller «denne skjermen trenger mindre innhold».
Telefon og video er fortsatt gode samtalekanaler, men de bør ikke være selve lagringsstedet for produktet. Kunden trenger en avgrenset arbeidsflate som alltid viser gjeldende prototype. I en privat kundevisning kan innspill samles uten at andre kunder, interne meldinger eller markedsføringsdemoen blandes inn.
Jeg bruker prototypen til å fjerne usikkerhet
Den første testen handler ikke om hvilken database som skal brukes. Den handler om hvem appen er for, hvilken oppgave personen prøver å løse og hva som må være sant når oppgaven er ferdig. Hvis dette er uklart, gjør mer kode bare usikkerheten dyrere.
- Avgrens én brukerreise. Velg én person, én oppgave og ett tydelig sluttpunkt.
- Gjør reisen klikkbar. Bruk ekte ord og realistiske tilstander i flere telefonstørrelser.
- La kunden prøve. Se hvor forklaringer må gis, og hvor grensesnittet kan forklare seg selv.
- Velg teknologien etterpå. Avklar native plattform, data, innlogging, varsler og publisering når behovet er tydeligere.
Hvorfor dette også er reklame på riktig måte
App Studio skal vise hvordan vi arbeider, ikke late som en kundes app allerede er ferdig. Derfor kan alle prøve en fiktiv demonstrasjon, mens faktiske kundeprosjekter får egne tilganger. Metoden er synlig; kundens kunst, kommentarer og forretningsdetaljer forblir private.
For meg er dette mer overbevisende enn et skjermbilde av en polert telefon. Besøkende kan bytte enhet, endre størrelse og prøve flyten selv. Samtidig er begrensningene skrevet rett ut. Demonstrasjonen viser både ambisjonen og arbeidsmåten.
Den dyre utviklingen skal begynne på riktig problem
Prototype først er ikke en snarvei rundt ordentlig apputvikling. Det er en måte å sikre at den ordentlige utviklingen starter med en brukerreise som allerede er sett, prøvd og diskutert. Når vi senere bygger kompilatorer, API-er og distribusjon rundt den, vet vi bedre hvorfor de trengs.
When we began sketching an App Studio for IntentForce, it was tempting to start with frameworks, build pipelines, and app stores. I chose a different starting point: the phone the client will actually hold and the one journey the app must make understandable first.
The result is a clickable browser prototype where iPhone and Android views, screen size, orientation, and colour theme can be tried before we lock in the expensive part of development.
A prototype gives the conversation a shared centre
A drawing can explain where a button may go. A live preview lets the client press it and feel whether the flow makes sense. That difference matters. When the client and developer see the same version, feedback becomes concrete: “this action must come earlier,” “that word does not fit the audience,” or “this screen needs less content.”
Phone and video remain useful communication channels, but they should not be where the product itself lives. The client needs a bounded workspace that always presents the current prototype. A private client view can collect feedback without mixing in other clients, internal messages, or the public marketing demo.
I use the prototype to remove uncertainty
The first test is not about the database. It is about who the app is for, what that person is trying to do, and what must be true when the task is complete. If those answers are unclear, more code only makes the uncertainty more expensive.
- Bound one user journey. Choose one person, one task, and one clear finish.
- Make the journey clickable. Use real words and realistic states across several phone sizes.
- Let the client try it. Notice where explanations are required and where the interface can explain itself.
- Choose technology afterwards. Decide on native platforms, data, authentication, notifications, and publishing when the need is clearer.
Why this is also honest marketing
App Studio should demonstrate how we work, not pretend that a client’s app is already complete. Everyone can therefore try a fictional demonstration, while real client projects receive their own access. The method is visible; the client’s art, comments, and business details remain private.
To me, this is more convincing than a screenshot of a polished phone. Visitors can switch devices, change sizes, and try the flow themselves. The boundaries are stated just as clearly. The demonstration presents both the ambition and the working method.
Expensive development should begin on the right problem
Prototype-first is not a shortcut around proper app development. It is a way to ensure that proper development begins with a user journey that has already been seen, tried, and discussed. When we later build compilers, APIs, and distribution around it, we have a much clearer reason for each part.