Insights from PixelPivot BD

Inside PixelPivot BD: How a Dhaka Software Team Builds Products That Last

PixelPivot BD began with a frustration that anyone who has commissioned software will recognise. A project is scoped, quoted, built and handed over — and within a year it is quietly abandoned. Not because the code stopped working, but because nobody could extend it, nobody documented it, and the people who wrote it had long since moved on.

We started this studio in Dhaka to work the other way around. Every engagement is treated as the beginning of a product's life rather than the end of a contract. That single decision shapes almost everything else about how we operate.

What we actually build

We are a software company first and a web studio second. Our work falls into four broad areas:

• Custom web applications — internal tools, customer portals, booking and management systems built around a specific business process.
• Business platforms and ERP — inventory, accounts, HR and operations software for companies that have outgrown spreadsheets.
• E-commerce systems — storefronts with the payment, delivery and inventory integrations the local market actually uses.
• Mobile applications — Android and iOS products, usually sharing a backend with an existing web platform.

Increasingly, clients also ask us to add AI features to existing products — assistants, smart search, document extraction, workflow automation. We take those on where they solve a real problem, and we say so plainly when they would only add cost.

How the team is organised

We keep the team small and senior-weighted on purpose. Two founders lead product direction and architecture; a lead engineer runs day-to-day delivery; and specialists cover frontend, backend, design, QA and deployment. On most projects a client works with three or four people, not a rotating cast of a dozen.

That structure has a practical consequence: the person who designed your data model is still reachable eighteen months later when you want to add a feature. For a business depending on software it did not write itself, that continuity is worth more than any technology choice.

The standards we hold ourselves to

If we cannot explain a technical decision to the client in plain language, it is usually a decision we have not thought through properly.

A few commitments apply to every project we take:

• You own everything. On completion, the source code, assets and infrastructure accounts are yours outright. No hostage arrangements, no licensing games.
• Working software early. You see a running system in the first weeks, not a slide deck at the end.
• Written scope, written change. Estimates come with what is included and what is not. When scope shifts, cost and timeline are re-quoted before work continues.
• Support is a service, not an afterthought. Post-launch maintenance is an explicit agreement with defined response expectations.

How we engage

Three models cover almost every request that reaches us. A dedicated team works best for evolving products where requirements will keep changing. A fixed-price project suits well-defined scopes where budget certainty matters more than flexibility. And a support and maintenance agreement covers software already in production — including systems somebody else originally built.

If you are not sure which fits, that conversation is free and usually takes twenty minutes. We would rather tell you your project does not need us than take on work we cannot do well.

7 Questions Every Business Should Ask Before Buying Custom Software

Most software regret traces back to questions nobody asked before the contract was signed. These are the seven we wish every client put to us — and to every other agency they are considering. A good partner will answer all of them without hesitating.

1. Who owns the code when this is finished?

The answer should be "you", in writing, in the contract. Some vendors retain ownership and license the software back to you, which means you cannot change suppliers without rebuilding from scratch. Ask specifically about source code, design files, and the accounts your system runs on.

2. What happens when requirements change mid-project?

They will change — that is normal, not a failure. What matters is whether there is an agreed process for it. A vendor who says "no problem, we'll handle it" without describing how change is scoped and priced is setting up an argument for month four.

3. When do I first see something running?

If the answer is measured in months, treat it as a warning. Long silences between payment and delivery are where projects quietly go wrong. You should be clicking through a real, if incomplete, system within the first few weeks.

4. Who exactly will work on this?

Agencies often sell with senior staff and deliver with juniors. Ask for the actual names and roles of the people assigned, and whether they are dedicated or split across several projects at once.

5. What is explicitly not included?

The exclusions matter more than the inclusions. Content entry, data migration from your old system, third-party licence fees, payment gateway registration, training — each of these is commonly assumed by the client and excluded by the vendor.

6. What does support cost after launch?

Software needs hosting, security updates, dependency upgrades and occasional fixes. Get the ongoing figure before you commit to the build figure. A cheap build with an expensive, mandatory support contract is not a cheap project.

7. Can I speak to a client you delivered for two years ago?

Recent references are easy. References from projects that have had time to age tell you whether the software survived contact with reality — and whether the vendor stayed responsive once the invoice was paid.

If a vendor gets defensive about any of these seven, you have learned something useful for the price of one meeting.

Why We Ship Every Two Weeks Instead of Once at the End

The traditional way to run a software project is to gather requirements, disappear for several months, and return with a finished system. It is tidy on paper. In practice it concentrates every risk in the project into the single worst moment to discover it — the day before launch.

What a long cycle actually hides

During a six-month silent build, three things drift apart: what the client described, what the client meant, and what the team built. Nobody is at fault. A written requirement is a compressed summary of an idea, and decompression errors are inevitable.

The problem is not that misunderstandings happen. It is that a long cycle lets them compound. A wrong assumption in week two becomes the foundation for weeks three through twenty-four, and correcting it at the end means unpicking everything built on top.

What changes with short cycles

We work in two-week increments. At the end of each, there is something running that the client can open and use — imperfect, incomplete, but real. That single habit changes the economics of being wrong:

• Corrections stay cheap. Two weeks of work is affordable to redo. Six months is not.
• Feedback gets concrete. People struggle to review a specification. They have no trouble at all telling you a screen is confusing.
• Progress becomes verifiable. "Sixty percent complete" is an opinion. A working feature is a fact.
• Priorities can move. When the market shifts in month three, the plan can shift with it.

What it asks of the client

Short cycles are not free. They require someone on the client side who can look at the work and give a decision within a few days. When that person is unavailable, the cycle stalls and the benefit disappears — so we agree who that person is before the project starts.

They also require tolerating unfinished work in view. The system will look rough in week four. That roughness is the point: it is what lets you steer while steering is still cheap.

A project that fails in week six is a small, recoverable problem. The same failure discovered in week twenty-six is a different kind of event entirely.

We would rather show you something imperfect early and be told it is wrong than protect our reputation for six months and be told the same thing when it is expensive to fix.

From Spreadsheets to ERP: Five Signs Your Business Has Outgrown Excel

Spreadsheets run more businesses in Bangladesh than any ERP system ever will, and for a long time that is exactly the right call. They are cheap, everyone can use them, and they bend to whatever process you already have. We have talked plenty of prospective clients out of buying software because their spreadsheet was still doing the job.

But there is a point where the spreadsheet stops saving money and starts costing it — quietly, in hours rather than invoices. These are the five signals we look for.

1. Someone's full-time job is copying data between files

Sales export goes into the stock file, the stock file feeds the accounts file, the accounts file gets re-keyed for the monthly report. When a staff member spends several hours a week moving numbers from one sheet to another, you are already paying a salary for what software does for free — and paying it every month forever.

2. Nobody is certain which file is current

inventory_final_v3_updated_NEW.xlsx. If your team hesitates before answering "which one is the real one?", you have lost the single source of truth. Decisions are now being made on data that may or may not be correct, and nobody can tell the difference until something goes wrong.

3. Only one person really understands the file

Most mature spreadsheets have an author — the person who built the formulas, knows which columns must not be sorted, and gets called whenever it breaks. That is a serious business risk sitting in one employee's head. When they take leave or resign, the process leaves with them.

4. You cannot answer basic questions quickly

"What did we sell to this customer last year?" "Which products are below reorder level right now?" "What is outstanding across all branches?" If these take a day of manual work instead of a few seconds, you are not running blind exactly — but you are running with a serious delay between reality and knowing about it.

5. Errors are being caught by customers, not by you

A wrong price on an invoice, stock sold that was not actually available, a duplicate order. Spreadsheets have no validation and no permissions — any cell can be overwritten by anyone, silently. When mistakes start reaching customers, the cost is no longer just internal.

One or two of these signs is normal. Four or five at once means the spreadsheet is no longer supporting the business — the business is supporting the spreadsheet.

What a sensible first step looks like

The mistake we see most often is trying to replace everything at once. A twelve-month, all-departments ERP rollout is how these projects fail. We almost always recommend the opposite:

• Start with the worst pain. Pick the single process that costs the most time — usually inventory or invoicing — and move only that.
• Keep the spreadsheets running alongside. For the first weeks, both systems operate in parallel. It is duplicated effort, and it is worth it.
• Migrate the data properly. Years of history in a spreadsheet is an asset. Cleaning and importing it is real work that belongs in the project scope, not an afterthought.
• Expand only once the first module is genuinely used. Adoption is the real test, not delivery.

Done this way, a business gets value within weeks and can stop at any point if the remaining spreadsheets are working fine. That is a much healthier place to make decisions from than a signed contract for a system nobody has seen yet.