Customer workflows
The tasks users need to complete, from onboarding and creating records to reviewing work or exporting results.
SaaS development for a defined first release
We build software products of our own and take on selected client engagements. Our SaaS development work starts with a concrete customer workflow, then defines the accounts, application features, integrations and operational work needed to support it.
Shape the product around its users
A new product does not need every possible feature at launch. We can scope the parts needed for a usable release or a focused improvement to an existing application.
Two products we built ourselves
Corcava and AtmosCompute are our own products. Their public workflows show two different kinds of software product work: running a service business and managing cloud infrastructure.
Our own product
Corcava: from customer work to invoicing
We originally developed Corcava for internal use. It combines CRM, project management, tasks and time tracking. The current product connects customer records, projects, tracked time, invoices and a client portal.
The useful starting point for a similar product is the full workflow: who creates a record, who acts on it next and which information needs to follow it.
Read the Corcava case studyOur own product
AtmosCompute: a dashboard for cloud resources
AtmosCompute brings GPU and VPS provisioning into a web control panel. Our work includes its Laravel backend and orchestration layer. The product supports Docker environments, a REST API and hourly billing.
It illustrates a different product scope: give users controls for an external resource, expose its state and connect usage to billing.
Read the AtmosCompute case studyStart with one complete customer workflow
An MVP needs a useful path through the product. For a service-business tool, that could mean creating a customer record, delivering a piece of work and preparing an invoice. Choose the smallest release that completes that path, then separate optional features from launch requirements.
For an existing product, the starting point may be a specific obstacle: a difficult onboarding flow, a missing integration or an operation that still needs manual work. A focused improvement can be scoped independently of a full rebuild.
Decisions that shape the scope and cost
Accounts and permissions: decide whether customers are individuals or organizations, how invitations work and what each role can see or change. If organizations share the application, define and test the boundaries between their data.
Billing: choose whether access depends on a subscription, usage or a combination. Plan what happens when payments fail, plans change or accounts close. Payment-provider integration is one part of that workflow.
Integrations and operations: identify external systems, imported data and long-running tasks. Include failure handling, support access, deployment responsibilities and recovery requirements in the plan.
Release and learning: define acceptance criteria and the first user actions you want to measure. An estimate should distinguish the initial release from ongoing hosting, maintenance and subsequent development.
How an engagement takes shape
Start with a written brief: the intended users, the problem, an example workflow, existing systems and your constraints. We review the fit and agree scope and availability before work begins.
Depending on the engagement, deliverables can include a prioritized release plan, implemented application flows and integrations, tests for agreed critical paths, deployment notes and a handover. The proposal should state what is included, what you need to provide and how later changes will be handled.
Agree where requirements, code reviews and release decisions will be recorded. Our GitLab vs Jira comparison helps define those responsibilities and when connecting the two tools is useful.
Our Laravel development page describes the backend and application work in more detail.
Start here
Send a written brief through our contact page: who the product is for, what users need to accomplish and whether you are starting fresh or extending an application. Scope and availability are agreed for each project.
Discuss your productSaaS planning guides
Define the first release, estimate its cost, investigate scaling decisions and agree who owns delivery. Each guide addresses a different part of the work.
What goes into a SaaS development budget?
Work through a scoped example budget, identify the assumptions behind an estimate and separate initial development from recurring operating costs.
Read the SaaS cost guidePlan the first usable release
Follow a client-approval example from the customer workflow through roles, subscription access and pilot acceptance checks.
Read the SaaS application guideMake architecture and scaling decisions
Define the workload, investigate database and queue constraints, and verify that tenant boundaries survive a change.
Read the SaaS architecture guideChoose and manage a delivery partner
Compare relevant evidence, define a bounded assessment and agree access, review responsibilities and handover.
Read the SaaS outsourcing guide