A focused first product
Operational Product & Dashboard MVP
You have a workflow, a data problem, or an internal product idea. In two weeks, we build one focused slice that people can test before you commit to a larger product.
The risk of building too much too soon
A useful product idea can become an oversized software project before anyone has tested the workflow. This offer keeps the first step deliberately small: one user need, one data source, one testable slice.
What two weeks buys
One useful workflow, chosen deliberately
We pick the user, decision, or repetitive process that matters most, then build around how people actually work — not a generic CRUD screen.
Real data in a usable view
One agreed source, prepared just enough for the pilot and presented through the one interaction that helps people decide what to do next.
A practical test environment
A controlled way for the agreed users to try the slice. Full authentication, permissions, and multi-tenant access are separate scope when the pilot proves it deserves them.
A clear handover
A working slice, short README, known limitations, and a next-step recommendation. The goal is a sound decision, not the illusion that a full platform appeared in two weeks.
How it runs
First we define the user, the workflow, the one data source, and the one decision the product must improve. Then I build a working slice, test it with the people who will use it, and document what it proves and what it does not. Authentication, additional integrations, production hardening, and further modules stay out of scope unless we agree them separately.
Where this comes from
In Soteria, I connected accident data with maps, charts and contextual panels. In SWARCO CCAM, I designed and built live traffic dashboards using WebSocket data. Those are the documented examples behind this offer to build a focused data interface.
What you get out of it
- A testable product or dashboard slice in two weeks, not a year-long project nobody commits to
- One real workflow tested with the people who use it
- Known limitations instead of hidden delivery risk
- A roadmap that says what to build next, and what not to
What it costs
€4,000
fixed, two-week product or dashboard slice
One focused workflow, one agreed data source, and one test environment. Larger products need a separate scope.
All figures exclude VAT and are invoiced in EUR, company to company, through TARG.DIGITAL SRL.
Is this the right fit?
A good fit if
- A product idea or operational workflow needs evidence before a larger build
- You have real data to build against, even if it is messy
- You want to test the idea with real users before committing to a platform
- Your team can review the evidence and decide what deserves a larger build
Probably not if
- You need a specific module added to an existing product — this is a focused MVP, not open-ended feature delivery
- Nobody has used the current manual process long enough to know what it actually needs
- The requirement is a full analytics platform, many integrations, or several user groups rather than one focused slice
How we'd work together
Scoped in a short call around one workflow, one accessible data source, and one test environment, then delivered as a fixed two-week engagement with an agreed definition of done. No hourly billing and no overage.
Questions people ask first
What if we don't have clean data?
We do not need perfect data, but we do need one accessible source and enough sample records to test the workflow. Joining several legacy systems or building a full ingestion pipeline is separate scope.
How is this different from the one-week prototype?
The prototype answers whether one map view or interaction is viable. This two-week slice tests one operational workflow around an agreed data source. Neither is a full platform, and both are designed to reduce uncertainty before a larger build.
What happens after the two weeks?
You get a focused working slice and a decision about what deserves to be built next. You can extend it with your team, ask me to build the next slice, or stop with useful evidence rather than an oversized commitment.
Can you work with our existing stack, or does it have to be Angular?
My documented frontend experience includes Angular and TypeScript. We assess your existing stack during scoping and agree on the implementation approach before committing. A new platform or several integrations needs a separate scope.
Does this match what you're facing?
Tell me about your stack and where it hurts. If I'm not the right person for it, I'll say so.