How we work
Eightstages,andyoucanseetheworkateveryone.
Every Apoliums project runs the same route from a first conversation to software in production and supported. Each stage below states what happens, what you receive, how much of your time it takes, and what it leaves behind.
- Stages
- Eight
- Cycle length
- One week
- You see
- Running software
- Every week
- A written update
Discover
Work out what the business needs before anyone agrees what to build.
What happens
- Sessions with the people who will use the software and the people paying for it — usually different answers from each.
- A walk through whatever runs today: spreadsheets, an old system, a manual process, an existing codebase.
- Constraints written down early — compliance, integrations you cannot drop, a date the business cannot move.
Deliverables
- Problem statement and success criteria
- Current-state map and pain points
- Constraint and integration inventory
Your involvement
High. Two to four working sessions, plus access to whoever knows how the current process really works.
Typical output
A written brief both sides agree describes the same problem.
Define
Cut the idea down to a first release that can actually ship.
What happens
- Everything discovered gets split into what the first release needs, what version two can carry, and what should not be built at all.
- User stories written with acceptance criteria, so 'done' is testable rather than debatable.
- Sequencing by risk: the parts most likely to be wrong get built first, not last.
Deliverables
- Scoped backlog with acceptance criteria
- Explicit non-goals for release one
- Cost range, timeline and assumptions
Your involvement
Medium. One review session and a written sign-off on scope and non-goals.
Typical output
A scope you can approve, with the trade-offs visible.
Design
Draw the screens and the flows people will actually work in.
What happens
- Flows first — what a user does start to finish — then wireframes, then visual design on the screens that carry the product.
- A component set rather than a pile of screens, so the build stays consistent and the tenth screen is faster than the first.
- States nobody asks for get designed anyway: empty, loading, error, no permission, too much data.
Deliverables
- Key flows and wireframes
- Visual design for primary screens
- Reusable component and token set
Your involvement
Medium to high. Review rounds on flows and on the first screens; later screens usually need only a look.
Typical output
Screens the team can build from without guessing.
Architect
Settle the data model, the boundaries and the failure behaviour.
What happens
- The data model comes first — entities, relationships, state transitions — because it is the decision refactoring cannot cheaply undo.
- Service boundaries, authentication and authorisation model, and the API contract are written before implementation starts.
- Every external call, payment and background job is designed as retryable and concurrently callable, with idempotency where it matters.
Deliverables
- Schema and migration strategy
- API contract and error catalogue
- Infrastructure and environment plan
Your involvement
Low to medium. One technical review, plus your team if there are systems to integrate with.
Typical output
A design decision record your future engineers can read.
Build
Ship vertical slices, weekly, into an environment you can open.
What happens
- Work runs in weekly cycles. Each one ends with something working end to end — database through interface — not a layer that is 80% done.
- Code review on every change, with types, linting and tests running in the pipeline before anything merges.
- A written update every week: what moved, what is blocked, what changed in scope and what that costs.
Deliverables
- Working software in a staging environment each week
- Weekly written progress note
- Repository, CI pipeline and environments in your accounts
Your involvement
Medium. One call a week and quick answers when a product question blocks a decision.
Typical output
A running system that gets more useful every week.
Test
Prove it behaves under the conditions that actually occur.
What happens
- Unit tests on logic, integration tests against a real database, and end-to-end tests on the paths that would cost money if they broke.
- Edge cases built as fixtures: the empty account, the enormous account, the duplicate submission, the payment that half-succeeded.
- Accessibility and browser checks on the screens users live in, plus load testing where traffic is expected to spike.
Deliverables
- Automated test suite running in CI
- Accessibility and cross-browser report
- Fixed defect log with severity
Your involvement
Medium. A user-acceptance pass by the people who will run the system daily.
Typical output
A release you can sign off on evidence, not on assurance.
Deploy
Put it in production without a blackout window.
What happens
- Containerised builds through a pipeline that runs the same steps for staging and production, so a release is a non-event.
- Migrations planned in expand-migrate-contract order, so the old version and the new one can run at once and a rollback stays possible.
- Logging, error reporting, uptime checks and backups switched on before the first real user arrives.
Deliverables
- Production environment with CI/CD
- Monitoring, alerting and backup configuration
- Runbook and rollback procedure
Your involvement
Low. Domain, DNS and third-party account access, and a go decision on the date.
Typical output
A live system with a way back if the day goes badly.
Scale
Keep it running, then make it worth more.
What happens
- Dependency and security updates on a schedule, not when something breaks.
- Performance work driven by traces and real user data, targeting what is slow in production rather than what feels slow in review.
- New capability planned in the same cycles as the original build, with the same written scope and estimates.
Deliverables
- Support arrangement with a defined response time
- Monthly report on uptime, errors and cost
- Roadmap for the next set of changes
Your involvement
Low, by design. A monthly review; more when you want new work planned.
Typical output
Software that stays cheap to change in its second year.
Two things this process refuses to do
No silent months. No surprise invoice.
A project never runs longer than a week without something you can open and a note explaining what changed. If a week produced nothing worth showing, that is the news, and you get it in that week rather than at the end.
Scope changes are priced before they are built. New information changes plans constantly — what should not change is that you decide, in writing, what it costs and what it displaces.
Start here
Have a product in mind? Let's build it.
Stage one is a conversation, and it costs nothing. Tell us what the business needs to do.
- info@apoliums.com
- Phone
- +91-99770-04451
- Studio
- Indore, Madhya Pradesh
- Reply time
- One working day