01 — Work
These are representative scenarios — honest illustrations of the kind of build we take on, how we would scope it, and what you would receive. The four below cover the engagement types we are set up for: internal tools, SaaS products, mobile apps, and taking over a system someone else built.
What these are: worked examples written by us to show our approach. What these are not: past client engagements, and none of the organisations described are real.
Scenario 01 — Internal tool
A field-services firm runs jobs from a shared spreadsheet that breaks weekly. We would run a one-day discovery workshop, then build a web app in roughly six weekly iterations: job board, engineer rota, customer notifications and a simple audit log — importing the existing spreadsheet so day one starts with real data.
Typical shape: 6–8 weeks · fixed quote · web app + care plan.
Scenario 02 — SaaS MVP
A founder has a validated idea and a deck, but no product. We would cut the feature list to a genuine MVP in a scoping workshop, then ship a multi-tenant web app with authentication, Stripe-style store billing and an admin panel — demoing weekly so the founder can show progress to backers.
Typical shape: 8–12 weeks · fixed quote · staged milestones.
Scenario 03 — Mobile app
A business with a working web platform wants an app its customers actually open: bookings, push reminders, offline access to documents. We would build for iOS and Android against the existing API, and handle store listings, review submission and the privacy declarations end to end.
Typical shape: 10–14 weeks · both stores · phased rollout.
Scenario 04 — Rescue & care
A company depends on software whose original developer has moved on. We would start with a short paid audit — dependencies, security posture, deploy process, documentation gaps — then a stabilisation sprint, then a monthly care plan with an SLA so the system has an owner again.
Typical shape: 1–2 week audit · then monthly care plan.
02 — Studio apps
We also build our own utility apps under the Thinkpod Studios name for the Apple App Store and Google Play. They double as public proof of our mobile work, and we link each one here as it is released. Our Privacy Policy covers these apps.
03 — Get in touch
Send a few lines: what the software should do, who has to use it, and whether a date is driving it. A human engineer answers, usually by the end of the next working day.
first answer: next working day