Product design and platform
CheckMyRef
A platform for storing, managing and reusing employment references, with a brand built around clarity and trust.
Read the case studyVisit product (checkmyref.com, opens in a new tab)
SaaS and MVP development
A first release that is small, and still a real product.
Phigz helps founders and product teams ship the first version of a SaaS product without treating it as disposable. The MVP is narrow. The foundations are not casual.
The problem
An MVP that only proves a slide is expensive twice: once to build, and again when real users arrive and nothing can be kept.
The other trap is over-building. Teams design the company they hope to be and miss the one workflow a customer would pay for.
We cut scope in the product, not in the engineering habits. Accounts, data and deployment are real. Features that can wait, wait.
What Phigz delivers
A sharp first workflow
The path from signup to the outcome the product promises. Secondary ideas are listed, then left out.
Multi-tenant basics
Accounts, roles and separation of customer data, designed before the second customer arrives.
An operable admin
Enough internal tooling to see who signed up and to support them, without a second product.
A launch path
Environments, a repeatable build and a list of what the next release should learn from the first users.
Where it fits
A founder with a validated problem
You can describe the user and the job. You need the product, not another workshop.
A pilot inside a larger company
A contained SaaS-style tool for one department, built so it can be retired or expanded honestly.
An MVP that already exists and is fragile
We stabilise the core path and make the next features possible, instead of restarting from a blank repository.
Delivery
01
Cut the release
We write the first version as a list of what is in, and a longer list of what is not.
02
Design the core path
The signup, the main task and the moment a user gets value. Edge cases that block launch are included.
03
Build for a second release
Structure stays simple, but it is not a dead end. We avoid patterns you would have to throw away immediately.
04
Ship and learn
The product goes to a real environment. The next slice is chosen from what users actually do.
Technical capability
Typical shape
A TypeScript web app, a server API, a database and authenticated accounts. Billing is included when the business model needs it in version one.
What we leave out
Custom infrastructure, speculative microservices and features for audiences you do not have yet.
AI when it is the product
If the value depends on a model, it is designed in from the start. If it does not, we will not add a chat box to look current.
Related product work
Published case studies are product builds. Where a page is about AI, these projects show how Phigz ships a complete product. They are not labelled as AI systems.
Booking product
Test Dates
A booking product for learner drivers looking for earlier DVSA test dates, with availability monitoring and a mobile-first interface.
Read the case studyVisit product (testdates.co.uk, opens in a new tab)
Training platform
Bluetech Consulting
A training and career-support platform, designed around course discovery and a visual identity in professional blue.
Read the case studyVisit product (bluetechconsulting.com, opens in a new tab)
Questions
How small is an MVP?
Small enough that a specific user can finish one valuable job. We decide that boundary with you before build starts. There is no fixed page count.
Can we add AI later?
Yes. We keep the product’s data and permissions clear so a later model feature has somewhere honest to live. See our note on adding AI to an existing product.
Do you take equity instead of a fee?
Engagements are commercial project work. We do not advertise equity-only builds.
Next step
Talk through this engagement.
Tell us the product, the current state, and the outcome you need. We will reply with a straight view of whether this is the right shape of work.