Six ways we can be useful.

1. 01

   Web applications

   Custom software in the browser — portals, booking, ordering, and the tools customers log into.

   When the work no longer fits a spreadsheet or an off-the-shelf product, we design and build the web app around the way your team and your customers actually behave. The first release is small enough to ship, and solid enough to use on a Monday morning.

   • The flows people repeat: sign-in, create, update, approve, export
   • An interface for customers and a quieter one for staff
   • Accounts, permissions, and the empty states people hit on day one
   • A written handover so you are not stuck waiting on us for every change

   A good fit when

   You have a process that lives in inboxes, spreadsheets, or a tool everyone works around.

   Timing

   A first release is often 8–16 weeks, depending on how many roles the product has to serve.

2. 02

   Websites

   Marketing and content sites that explain the offer clearly and stay fast after launch.

   A website should make the next step obvious: book a call, request a quote, read the work, buy the thing. We write the structure, design the pages, and build a site your team can update without breaking the layout.

   • Page structure based on what a visitor needs to decide
   • Design that feels like the company, not a rented template
   • A way for your team to edit pages, case studies, and news
   • Speed, metadata, and the forms that actually reach a person

   A good fit when

   The current site is slow, vague, or embarrassing to send to a customer.

   Timing

   A focused marketing site is often 4–8 weeks. Larger content sites take longer, and we say so up front.

3. 03

   Mobile apps

   iOS and Android apps for customers, and for people who do the work away from a desk.

   We build mobile apps when a phone is the right place for the job — a field engineer, a driver, a member checking in. Shared code when one codebase will do. Native where the device itself is the product.

   • A first version limited to the jobs the app must do offline or on the move
   • Camera, location, and notifications only where they earn their place
   • A release path you can repeat, not a one-off build nobody can update
   • Store listings and a plain-English guide for the people who will use it

   A good fit when

   People need the product in their pocket, or the work happens somewhere a laptop will not go.

   Timing

   A focused first version is often 10–16 weeks, including the first store release.

4. 04

   Product design

   Flows, interface, and a component set a build can actually use.

   Design at Firmin is not a slide at the start of the project. We draw the screens people will touch, test the awkward paths, and leave a set of components the next release can reuse. Design can lead a build, or stand on its own if your engineers are already in place.

   • A map of who does what, before any visual design
   • Interface for the main path and the messy ones: errors, empties, permissions
   • A small component set, named and ready to build from
   • Notes for engineering so the design does not die in a handoff folder

   A good fit when

   You have a product and a team, and the interface is where the work keeps stalling.

   Timing

   A design engagement on an existing product is often 3–6 weeks.

5. 05

   Internal systems

   The tools staff open every day — scheduling, stock, approvals, and handoffs.

   The software that runs a company is rarely the public website. We replace the shared inbox, the whiteboard, and the spreadsheet that only one person understands, and connect the new tool to the systems you already pay for.

   • A close look at the workaround before we propose a replacement
   • Screens for the people who do the work, not a generic admin theme
   • Imports from the spreadsheet or tool you are leaving
   • Permissions, an audit of who changed what, and a backup of the old data

   A good fit when

   A process works only because one person remembers how.

   Timing

   Often 8–14 weeks for a first release that can replace the current workaround.

6. 06

   Launch care

   After go-live: fixes, measurement, and the next slice of the product.

   Launch is the start of people using the thing. We stay on for a monthly retainer when you want the same team to fix what real use uncovers, watch the numbers, and ship the next agreed slice. No ticket queue. No junior rotation.

   • A named person, and a monthly block of time written down
   • Fixes, small improvements, and dependency updates
   • A short note each month on what changed and what we would do next
   • Room to pause the retainer when you do not need it

   A good fit when

   You want the studio that shipped the product to keep looking after it.

   Timing

   Monthly, after a launch we were part of — or after we have taken over an existing product.

Not sure which one it is? Send the brief anyway. We would rather point you to the right shape of project than force a label.