Apps and products
From nothing to live, and actually used. Web applications, mobile apps and customer-facing portals, built, put live and looked after.
What it is
Apps and products, from the first screen to real users. We build and run our own products too, which keeps us honest about what it takes to get software used.
What we usually build
- Web applications
- Mobile apps
- Customer-facing portals
What changes
- Before: Clients emailing for updates.After: a portal they check themselves.
- Before: A process that only works on a laptop.After: an app for the team on the move.
- Before: A product idea in a notes app.After: shipped, with real users.
Before you call
- Who it's for
- Businesses that need something their clients or their team will actually open: a portal instead of update emails, an app for people on the move, a product idea that has been sitting in a notes app. Usually the owner, or the person who will answer for it being used.
- What you're left holding
- The app, its source code, every account it runs on, the deployment, and plain-English instructions somebody who did not build it can follow. If you never speak to us again, it carries on working.
Every job is scoped first, then given a fixed quote and dates in writing.
A real example
Slashturn Studios (our own product)
- Before
- Huge files split, compressed or sent through three different services.
- We built
- Cloud storage for creative professionals. Files too big for everything else go up whole, and preview in place. Share links expire, and deleted files can be restored. Live at usesera.io.
More work like this
Questions people ask
Who looks after it once it is live?
We can. We build it, put it live and look after it, and most of what we have built we still look after.
If you would rather run it yourselves, handover gives you everything you need to.
What do you actually build?
Internal systems, apps and the joins between them. A stock and ordering system, a board your team works from, a portal a client signs off in, and the automation that moves a job between them. Usually a web application, sometimes mobile, and always something somebody opens on a normal working day.
Why not hire someone in-house?
Sometimes you should, and we will say so. If the software is the business and it will need changing every week for years, your own team is the right answer.
Hiring costs you months, and the wrong hire costs more than that. We suit work that has a shape, a written scope and an end.
What if you do not like the work?
We would rather find that out in the first week than at handover, so you see working software early. If we think a build is going wrong, you hear it from us first.
You own what has been built either way. If you want to stop, say so and we stop.
What happens at handover?
You get the source, the accounts it runs on, the deployment, and written instructions somebody who did not build it can follow.
If you never speak to us again it carries on working, and that is the test we build to.