Software that ships, not software that demos.
Web and mobile applications built to a written specification, shown working every Friday, and handed over with the keys. The part of the job that everything else supports.
- 4 weeks
- typical scope to live
- Every Friday
- working software, not status
- Day one
- you own the repository
Who this is for
You probably need this if…
01
Your spreadsheet stopped coping
It started as one tab. Now four people edit it, two of them overwrite each other most weeks, and nobody can say which version is correct.
02
The quote you got was three months
For something you can describe in two paragraphs. Most of that quote is plumbing you should not be paying to have rebuilt from nothing.
03
You have the design but not the build
Figma files, a clear idea, maybe a prototype. What is missing is the team that turns it into something with a login and a database behind it.
What this covers
The work, in detail.
7 capabilities
01
Web applications
Customer portals, operational dashboards, booking systems and the internal tools that replaced a spreadsheet nobody trusts any more.
02
iOS & Android
One React Native codebase shipped to both stores, with native modules written for the places the cross-platform layer runs out.
03
API design
REST and GraphQL interfaces designed to be consumed by someone who is not you, and documented well enough that they can be.
04
Real-time features
Live dashboards, presence and collaborative editing, plus the reconnect logic that decides whether any of it survives bad hotel wifi.
05
Offline-first
Applications that keep working in a stockroom with no signal, and reconcile cleanly when the phone finds the network again.
06
Progressive web apps
Installable, push-capable web applications for teams who should not have to find you in an app store to do their job.
07
Frontend performance
Core Web Vitals, bundle discipline and render behaviour treated as a requirement in the spec rather than a cleanup task at the end.
How we approach it
Positions we actually hold.
Opinions cost something to have. These are the ones we would argue for on your project, including where they make the work slower.
01
Specification before keyboard
Week one produces a written scope you sign. No code until then. It is the cheapest week in which to change your mind, and the most expensive one to skip.
02
Friday demos, not status reports
Every Friday you click something real with your own data in it. Percentage-complete is a number that can be quietly wrong for six weeks.
03
Boring technology on purpose
We choose tools with large hiring pools and long support horizons. The clever choice is fun for us and expensive for whoever maintains it next.
04
You own it at the end
Repository, infrastructure accounts, domains, documentation. Handover is a deliverable with a checklist attached, not a conversation at the end.
Technology
What we work with.
Defaults, not requirements. If you already run something else and have a team who knows it, we work in yours.
- Frontend
- React 19, Next.js, TypeScript, Tailwind CSS
- Mobile
- React Native, Expo, native modules where needed
- Backend
- Node.js, PostgreSQL, Prisma, REST & GraphQL
- Quality
- Playwright, Vitest, typed contracts end to end
Where this shows up in delivery
- Charten, our clinical charting product, is a production React and Next.js application with live users.
- Larder runs an offline-tolerant inventory flow built for stockrooms where the signal drops.
- Every engagement inherits Sill, so accounts, permissions and billing work on day one rather than week three.
Bought as part of
Web Applications
Fixed-price project
Mobile Apps
Fixed-price project
AI Integration
Fixed-price project
Dedicated Teams
Monthly retainer
This practice is never sold on its own. It is quoted inside one of the engagements above, as part of a single number.
Proof
Where we have actually done this.
Projects we designed, shipped and wrote up. Each one names the decision that was genuinely hard to get right.
Questions
What people ask about product engineering.
- Can you work with our existing codebase?
- Yes. Week one becomes an audit instead of a greenfield scope. We read the code, map what is there, and tell you honestly what is worth keeping and what is costing you more than it saves.
- What if we already have a designer?
- Then we build to their files. We will flag anything that is going to be expensive or awkward to implement before we start rather than after, so they can adjust while it is still cheap.
- Do we get the source code?
- You own it from the first commit. The repository lives in your organisation, not ours, and it stays there whatever happens to the relationship.
- What happens if the scope changes mid-build?
- We re-quote the difference in writing before touching it. You approve it or you do not. Nothing gets silently absorbed and then billed as a surprise at the end.
Related reading
Written on this, by us.
How We Work · 8 min read
What Actually Goes in a Software Specification
A specification you can quote against is not a wish list. Here is what a useful one contains, what it deliberately leaves out, and how to tell a weak one.
Data & Integration · 7 min read
Multi-Location Is a Permissions Problem Wearing an Inventory Costume
Adding multi-site support with a location column works until one person holds different authority at two sites. Then it quietly leaks data.
Engineering · 7 min read
Offline-First Is Not a Feature, It Is a Decision You Make on Day One
Software used in a stockroom, a basement or behind a fridge will lose its connection. Retrofitting offline support is one of the most expensive changes in mobile development.
Tell us what you’re trying to build.
Describe the problem in your own words. We’ll come back within one business day with a scope, a number and a date.
Phone
+1 (407) 796-2376Reply time
One business day, from an engineer
Based in
Orlando, Florida · serving the United States
What happens next
- A reply within one business day, from an engineer
- A thirty-minute call, with no qualifying call before it
- A written scope and a fixed number, if it fits