A software studio that argues for less
We build web and mobile applications for businesses that need the software to fit the work, not the other way round. Often that means talking you out of half of what you came in asking for.
A studio built around one stubborn idea
Most software projects don't fail in the code. They fail in the gap between what someone asked for and what they actually needed â and that gap usually only becomes visible after the invoice.
Samadi exists to close it early. We spend the first conversation on the problem rather than the platform, and we write down what was agreed so that three months later neither side has to rely on memory.
It's also why we offer two routes instead of one. Some problems are common enough that an application we've already built and proven will cover them once it's tailored to you. Others are specific enough that anything off the shelf would cost more in workarounds than it ever saves. Steering someone toward the bigger project to win the bigger invoice is a short game.
What doesn't change either way: scope is agreed before work starts, you can open and use the app at every stage, and the code and the data are yours at the end.
If a smaller build solves your problem, we'd rather say so and keep the relationship.
- Ways to start
- 2
- Ready-made and tailored, or built from scratch. Both end in an app that's yours.
- Steps to handover
- 4
- Consultation, proposal, development, handover â the same for every project.
- Cost to talk first
- 0
- The consultation is free, and nothing is charged before an agreement exists.
- Yours at the end
- 100%
- Source code, accounts and data transfer to you. Staying with us is optional.
Six things we don't negotiate on
Not a poster on a wall. These are the calls we make when a project gets uncomfortable.
Understand the work first
We learn how your team actually operates before proposing anything that changes it.
Say the inconvenient thing
If a smaller build solves it â or an app isn't the answer â you hear that, not a bigger quote.
Build to be handed over
Structured and documented so another team could pick it up. Lock-in isn't a business model.
Estimate late, then hold it
Numbers come after understanding. When one turns out wrong, you hear it while options remain.
Boring where it matters
Proven tools for the parts that must not fail. Novelty is not a deliverable you asked for.
Finish things
Shipped and in daily use beats impressive and unreleased. Scope gets cut before quality does.
What we do, and what we won't
Every studio says it's transparent. It's easier to judge from the list on the right.
What we do
- Tell you when a cheaper route solves your problem
- Put scope, timeline and cost in writing before starting
- Design the screens before any code is written
- Give you something you can open and use at every stage
- Hand over the code, the accounts and the documentation
- Say early when an estimate turns out to be wrong
What we won't do
- Quote a number before we understand the work
- Promise a fixed feature list against a fixed date
- Hold your hosting or accounts to keep you around
- Bill you for fixing defects in what we delivered
- Add scope quietly and let the invoice explain it later
- Disappear the week after launch
A small team, and no handoffs
Whoever sits in your first consultation stays on the project. Nothing gets thrown over a wall to a team you've never met.
- 01
Product & scoping
Turns a brief into something buildable, and decides with you what waits.
- Problem framing
- Written scope and proposal
- Priority calls during the build
- 02
Interface design
Settles the screens and the flow while changing them still costs nothing.
- Screen and flow design
- Review rounds with your team
- Assets you keep
- 03
Engineering
Builds it â web, Android or iOS â and keeps each stage openable and testable.
- Application development
- Integrations and data
- Testing before a stage lands
- 04
Support & maintenance
Stays reachable after launch, on terms agreed before launch.
- Fixes and patches
- Updates and dependencies
- The next round of features
The part we can't claim ourselves
Whether the way we work actually works is not really our call to make.
âThey mapped out what we actually needed before building anything, so nothing was wasted. The estimate was laid out openly from the start.â
âWe started with the most basic version and added to it by priority. That way of working suits a small team like ours.â
âOur old app was continued rather than torn down and rebuilt. Communication was easy and we always knew where things stood.â
Tell us what isn't working
You don't need a specification or a budget to start. A description of the problem is enough for a first conversation.