Software & SaaS
Product development means getting from an idea to a first version real people can use, and deciding what to build next from what they do. We work as one team of product thinking, design, engineering and QA: a short discovery sprint, a scope cut to the smallest useful release, a prototype you can click, then a build in short iterations. It suits startups, internal tools and new lines inside existing companies. Send us the idea in a few lines and we reply within one working day.
A first release often carries every idea the team has ever had. It takes months, costs more than planned, and arrives before anyone has learned whether the main idea works. Or it goes the other way: a quick prototype that can't be built on, so the real version starts from zero.
We aim between the two. The scope is cut to the one job the product must do well, the design is tested before it is built, and the first release is real code that the next release can grow from. What you learn from use decides what comes next, not the original wish list.
One to two weeks to turn an idea into a written scope: who it's for, the job it does, what's in the first release and what is not.
A clickable prototype tested with a few real users before engineering starts, so the expensive mistakes happen on paper.
Working software every one to two weeks, each demonstrated, with design, engineering and QA in the same team.
The code and documentation handed to your engineers, or Teknoesis stays on as the team that keeps shipping.
Interviews with the people who will use it, a map of the workflow, a ranked list of features and a first-release scope you can sign. You also get the open risks: what must be true for this product to work, and the cheapest way to check each.
The smallest release that lets real people do the main job and tells you if it's worth continuing. In: the core flow, sign-in, and the one integration it can't work without. Out: reports, settings and edge cases that nobody has asked for yet.
Not every product is a startup. A tool that replaces a spreadsheet, a portal for partners or a new line inside an existing company follows the same path, with the staff who will use it involved from the first week.
Custom software for existing workflowsEvery product development project runs through our delivery process. These are the steps that are specific to this work. Teal steps are thinking, graphite steps are building, and orange ones keep it running.
Discovery sprint
Users, the job to be done, and the risks, written down in the first one to two weeks.
Scope the smallest release
Every feature argued for or cut. The first release is the shortest path to a real user doing the main job.
Prototype and test
Clickable screens, tried by a handful of real users before any production code.
Build in iterations
One to two week cycles, each ending in a demo on a preview link.
Test and release
QA on real devices, analytics in place, and a launch plan with a rollback.
Measure and decide
What users did, what they asked for, and which release comes next.
| Scope | Range |
|---|---|
| Discovery sprint | 1–2 weeks |
| Prototype and design | 2–4 weeks |
| First release (MVP) | 8–16 weeks |
Planning ranges, not quotes. Your scope sets the real timeline, which we confirm in writing after discovery. See how engagements are priced.
Began as a CRM for property agencies losing leads between Facebook ads and WhatsApp groups. It started from the channels and the owner's approval step, and now also serves e-commerce, education, clinics, travel and service teams.
Fixed scope, dedicated team and product partnership: which model suits a product.
Think, make, run: what happens in each phase and what you receive.
The same scoping mistakes show up in redesigns, and how to avoid them.
A prototype is screens you can click to test an idea, and it isn't meant to run in production. An MVP is working software that real people use for the main job, built so the next release can grow from it. We usually do both: prototype first, then the MVP.
We start from the one job the product must do well, and every feature has to argue its way in. Anything that isn't needed for a real user to finish that job, or for you to learn from it, waits. You see the cut list, so it's a shared decision.
The number of distinct flows, the roles and permissions, the integrations (payments, WhatsApp, a CRM), whether it needs a mobile app, and how much design work it needs. After the discovery sprint you get a written scope with a fixed price per milestone or a monthly plan.
A decision-maker who can answer questions within a day or two, access to a few people who will use the product, and the content or data that already exists. Without those, the sprint has to guess, and guesses are what we're trying to avoid.
Yes. The code lives in your repository from the first commit. Under our terms the final deliverables, designs included, are yours once the project is paid in full, and we keep only the general tools and libraries we use across projects.
Yes. You can hand it over to your own engineers with documentation and a walk-through, or keep us on as a dedicated team that works in your sprints, or as a product partner that also hosts and supports it. We discuss which fits at the end of discovery.
Multi-tenant subscription products: tenancy, roles, plans, admin tools, and the running of them afterwards.
Learn moreCRMs, internal tools, portals and multi-tenant SaaS with roles, permissions and integrations.
Learn moreUser flows, clickable prototypes and design systems, designed and built in the same place.
Learn moreiOS and Android apps with React Native and Expo, sharing an API with your web app.
Learn moreA few lines is enough. We'll ask the right questions on the call.
We reply within one working day
By email or WhatsApp, whichever you prefer.
A short call
To understand the goal, the people who'll use it and any deadline.
A written scope and estimate
Before any work starts, so you know what you're agreeing to.
Prefer to talk first?