GopalutInnovations Bring an idea

Software workshop · Causeyside Street, Paisley

Bring the idea. We weave it into something people can actually use.

Gopalut is a small, hands-on workshop for founders with a half-formed product. We sit down with your sketches, voice notes and spreadsheets, decide what the first useful version should be, then design, build and publish it with you.

Start with a conversationTry the Build-path picker

How an idea travels through the workshop

Nothing mystical: five practical stops, each finishing with something you can hold, test or decide upon.

  1. Unpack

    We listen to the idea as you tell it, then write it back as a short problem statement and a list of the people it must serve.

  2. Shape

    Paper flows become clickable screens. You see the product before a line of production code is written.

  3. Make

    Short build cycles with a working preview at the end of each, so decisions are made on real behaviour.

  4. Launch

    App store listings, domains, privacy text and the dull-but-vital checks that let a release go out calmly.

  5. Tend

    Fixes, updates and small improvements once people start using it and telling you what they think.

People around a table covered with sticky notes during a planning session
A planning wall is where most of our projects begin. Illustrative stock photograph — not Gopalut staff or client work.

Built for founders, not procurement departments

Many of the people who come to us have a day job, a deadline and an idea that keeps them awake. They do not need a forty-page proposal; they need someone who will ask the awkward questions early and then get on with making.

We keep the team you speak to the same team that designs and builds. You will always know what is being made this week, what it costs, and what we need from you to keep moving.

Inside the workshop

What leaves the workshop

Build-path picker

Three quick questions. The picker suggests where a first version might start; it is a conversation starter rather than a quote.

Who uses it first?
Where will they be?
What exists already?

Answer the three questions and a suggested path will appear here.

Overhead view of a workshop table with app sketches on index cards, a phone and coloured thread
Illustrative generated image of a first-session table. Not a photograph of our office or a client project.

Before the first session

What to bring to the table

A first conversation with Gopalut lasts about an hour. It goes further when you bring the raw material, however untidy. Nothing needs to be polished; half the value of the session is sorting it together.

  • The moment of need. Describe one real occasion when someone wished your product existed. Who were they, where were they and what did they do instead?
  • Anything already made. Sketches, screenshots, a spreadsheet that runs the business today, a competitor you admire or dislike.
  • Your constraints. A launch date that matters, a budget range you are comfortable with, rules your sector must follow.
  • Who decides. The name of the person who can say yes to a design, so decisions do not wait a fortnight.

You leave with a one-page summary: the problem in a sentence, the first people to serve, the smallest version worth building, and the questions still open.

First-version trimmer

Most first releases try to do too much. Sort these common features into Now, Later or Not needed and the trimmer tells you how heavy your first version is looking. Nothing is sent anywhere.

Sign-in and accounts
Payments
Push notifications
Admin dashboard
Booking calendar
In-app messaging
Maps and location
Reports and exports
Multiple languages
Offline use

0 features in the first version

Start sorting. A focused first version usually has three to five features in the Now column.

What changes hands at each stage

A workshop is fair when both sides know what they owe. This is what we ask of you, and what you receive, at each point.

StageYou bringYou leave with
UnpackYou bring: An hour, your notes, the people who decideYou leave with: A written problem statement and a proposed first version
ShapeYou bring: Feedback on screens within a few working daysYou leave with: A clickable prototype on your own phone and a costed build plan
MakeYou bring: Answers to questions, test content, a weekly half-hour reviewYou leave with: Working preview builds and a short written update each week
LaunchYou bring: Store and domain accounts in your name, final copy approvalYou leave with: Published product, completed release checklist, handover notes
TendYou bring: Reports of problems and ideas from your usersYou leave with: Fixes, platform updates and a readable change log

Borrow our one-paragraph brief

Founders often ask how to describe an idea without writing a document. This template is the one we use internally. Fill the gaps and you have something any studio, investor or friend can respond to.

For [who, specifically], who currently [what they do today],
we want to make [a mobile app / a website / a web tool]
that lets them [the one job it must do well].
They will mostly use it [where, on what device].
The first version is successful if [a measurable sign],
and it does not need [what can wait] yet.
We must launch by [date, and why that date matters].

After launch, the work changes shape

Once real people use a product, the useful questions change. Which screen do people abandon? Which feature did nobody ask for? Which phone model shows a layout fault? Our support arrangements exist to answer those questions steadily rather than in a panic.

Support is agreed per product. It usually covers fault fixing, operating-system and dependency updates, certificate and backup checks, and a small allowance for improvements. Requests are read Monday to Friday, 09:00–18:00 UK time, and every change is written up in plain English.

Support and the request form

Questions founders ask us first

I have no technical background. Is that a problem?

No. Most people we work with are experts in their field rather than in software. We explain choices in plain English and never ask you to choose between technologies you have not had explained.

Should my first version be an app or a website?

It depends on where people will use it and how often. A website or web app is faster to update and needs no store review; an app suits regular use, notifications and device features. The Build-path picker above gives a first view, and we discuss it properly in the first session.

Who owns the code and designs?

You do. Repositories, design files, store accounts and domains are set up in your name or transferred in full.

Can you work with a designer or developer I already know?

Yes. We can design for another team to build, build from another team’s designs, or review existing work before it launches.

How do you price work?

After the Unpack stage we provide a written estimate for the agreed first version, split by stage, with assumptions listed. Changes in scope are priced before they are made.

Do you sign non-disclosure agreements?

We are happy to consider a reasonable NDA before you share confidential details. You can also describe the idea in general terms first.

Got a voice note, a napkin sketch or a spreadsheet that has grown legs? That is enough to begin.

Bring an idea