Software
Builds that match the brief — not a stack slide.
We take software engagements after the problem is named: who uses it, what must be true on launch day, and what failure looks like. The site does not list every framework we have touched; it describes the kinds of products we have delivered and how those engagements ran.
Named references and metrics are shared in calls when a client clears them. What follows is the shape of work — written so you can see whether your project belongs here.
How we show expertise
Technology names do not appear in proposals unless they solve a constraint from the specification. On this page you see project types and anonymised case shapes — the same structure we walk through on a first call. When a client allows it, we add named references and metrics to the deck.
What you receive
Written scope, acceptance criteria, demo environments, handover notes, and — for running systems — observability and runbooks agreed in advance. Stack choices are documented as decisions, not as marketing keywords.
Project types
Each entry is a class of work we have run — with a case shape you can map to your brief. Details deepen on a call when confidentiality allows.
- Discuss Campaign & publishing
Campaign & publishing
Campaign sites that actually capture leads.
Film and media briefs often need more than a link in bio: localized landing pages, Bangla/English copy, forms that marketing trusts, and an admin view so producers see sign-ups per episode instead of a shared inbox thread.
What we prove: funnel tied to content IDs, not a one-off WordPress theme.
Case shape: an owned-channel sponsor arc with UTM-tagged sign-up, producer dashboard, and acceptance tests for mobile Safari — delivered in the same timeline as the edit lock.
- Discuss Operations & back-office
Operations & back-office
Internal tools that replace the spreadsheet everyone was afraid to delete.
Scheduling, approvals, inventory, or finance handoffs — modelled with roles, audit trail, and exports finance can reconcile. We start from who clicks what on Monday morning, not from a framework choice.
What we prove: the workflow is the product; technology follows the state machine.
Case shape: quote-to-cash for a regional brand — typed requests, approver queue, CSV export on close, and alerts when an integration stalls instead of silent data drift.
- Discuss Customer-facing product
Customer-facing product
Customer products that must survive launch week.
Auth, payments, notifications, and data boundaries are agreed in the specification before visual polish. Load characteristics and rollback are part of delivery — not a post-launch surprise.
What we prove: launch readiness is a deliverable, not optimism.
Case shape: subscription-style launch with staged traffic — load test on checkout, queue backpressure fixed before paid media, runbook for support when a third-party API degrades.
- Discuss Commerce & retail
Commerce & retail
Commerce when the platform checkout is not enough.
Shopify extensions, custom catalog rules, and ops dashboards when native admin cannot express the offer. Scope names what stays in Shopify versus what needs a service beside it.
What we prove: money paths are tested; edge cases are documented.
Case shape: bundle pricing and fulfilment exceptions — extension for checkout rules, webhook retries with a visible dead-letter queue for ops.
- Discuss Integrations & data
Integrations & data
Integrations that must stay consistent overnight.
Warehouse, ERP, payment, and partner APIs — with idempotent jobs, replay, and monitoring someone will actually read. Event-driven when coupling would break either side's release cycle.
What we prove: operators can trust tomorrow morning's numbers.
Case shape: nightly sync between fulfilment and finance with reconciliation report — failures alert with payload preserved for replay, not a silent partial import.
- Discuss Requirements only
Requirements only
Specification before code — when you need alignment, not a repo yet.
Users, behaviour, data, integrations, acceptance tests, and explicit out-of-scope. Stakeholders sign the document; build (by us or your team) follows it.
What we prove: shared definition of done before engineering hours.
Case shape: board-ready spec for a portal rebuild — role matrix, API contracts, migration cutover, and test scenarios legal can review before spend is committed.
Requirements first
We do not start a build from a slide deck. The specification defines users, behaviour, data, acceptance tests, and what is out of scope — then design and code follow that document.
What goes in a software requirements specification