Keepur — Inventory & Business Operations Platform

Overview

Keepur.app started from a problem I kept seeing in small businesses:

They were running real businesses, but managing critical operations through notebooks, spreadsheets, WhatsApp messages, and disconnected software.

For many small retailers, inventory software is either too basic or too complicated.

At one end, businesses use spreadsheets that become difficult to maintain as operations grow.

At the other end, full ERP systems introduce dozens of modules that a small shop does not need.

I wanted to build something in between.

That became Keepur.

A simple business operations platform that starts with inventory but can gradually grow with the business.

Why I Built It

The initial problem looked like inventory management.

But after speaking with businesses and thinking through their day-to-day operations, I realized stock quantity was only one part of the problem.

A shop owner needs to know:

• What products do I currently have?
• What came into stock?
• What was sold?
• Which shop has which product?
• Who performed a transaction?
• What is running low?
• Can I send an invoice to a customer?
• Can my employees access the system without having full control?
• What happens when I operate multiple branches?
• How do I track high-value products individually?
• Can I keep records without maintaining separate spreadsheets?

The problem was really about operational visibility.

Keepur was built to give business owners a single place to understand what is happening inside their business.

The Problem I Wanted to Solve

A lot of smaller businesses operate with fragmented workflows.

A typical process might look like:

Notebook → Calculator → Excel → Messenger/WhatsApp → Printed Invoice → Manual Stock Count

The business technically works.

But as the number of products, employees, transactions, or branches increases, the weaknesses become obvious.

Common problems include:

• incorrect stock quantities
• missing transaction history
• difficulty tracking who changed inventory
• manual invoice preparation
• duplicate data entry
• weak branch-level visibility
• no structured audit trail
• difficulty tracking expensive serialized products
• dependence on one employee who "knows everything"

I wanted Keepur to replace those fragmented operations with one structured workflow.

What I Built

Keepur started as an inventory platform, but the product evolved around actual business operations.

The system now focuses on several connected areas.

Product & Inventory Management

At the center of Keepur is product inventory.

Businesses can maintain their product catalogue and keep track of stock changes from one place.

The idea was to keep the workflow straightforward:

Add Product → Add Stock → Sell / Adjust → Track Remaining Inventory

Instead of making users understand a complicated ERP inventory model, the system focuses on the information small businesses actually need.

Multi-Shop Management

A major requirement was supporting businesses that operate more than one location.

A business owner should not need separate software accounts or spreadsheets for every branch.

Keepur is designed so multiple shops can operate under the same business environment while inventory and operational information remain organized.

This creates a foundation for businesses that start with one shop and later expand.

Team Access

A business owner is rarely the only person using the system.

Employees may need to:

• add products
• process transactions
• update inventory
• prepare documents
• handle shop operations

But giving every employee complete control creates risk.

So Keepur includes team-oriented functionality that allows business operations to be shared without treating every user as the owner.

This was an important step toward turning Keepur from a personal inventory tool into a proper business platform.

Serial Number Tracking

One of the more interesting problems came from businesses selling products where quantity alone is not enough.

Imagine a store selling:

AirPods, phones, electronics, appliances, devices or other individually identifiable products.

Knowing that there are "10 units" in stock is useful.

But the business may also need to know exactly which 10 units are available.

That means tracking information such as individual serial numbers.

I designed serial-number tracking as an advanced capability rather than forcing every business to use it.

For normal inventory:

Product → Quantity

For businesses that need deeper tracking:

Product → Individual Unit → Serial Number

This keeps the basic product simple while allowing more complex businesses to upgrade when necessary.

Sales & Transaction Records

Keepur also acts as a historical record of business activity.

Rather than only showing the current stock count, the system is designed around the idea that businesses need to understand how the stock reached that number.

That means keeping structured records around movements and transactions.

This is important because inventory without history creates another problem:

If the number is wrong, nobody knows why.

A useful inventory system should not only answer:

"How many do I have?"

It should also help answer:

"What happened?"

SMS Invoice

One problem I wanted to solve was invoice delivery.

For many local businesses, customers do not necessarily need another account or app just to view an invoice.

So I designed a simple SMS invoice workflow.

The concept is:

Create Invoice → Generate Public Invoice Link → Send Through SMS → Customer Opens Invoice

This allows the business to provide a digital invoice without forcing the customer through an onboarding process.

The SMS system was also designed around credit/balance management so that messaging could become a sustainable paid service rather than an unlimited operational cost.

Delivery Challan

As the product expanded, another practical workflow became important:

delivery documentation.

Businesses frequently need a record of goods being transferred or delivered even when that document is not the final sales invoice.

Keepur therefore includes delivery challan functionality as part of the operational workflow.

This is a good example of how the product evolved.

The feature did not come from trying to make the feature list bigger.

It came from understanding what businesses actually do between inventory and final payment.

Subscription Management

Because Keepur is a SaaS product, I also had to solve problems that normal client projects do not require.

For example:

• trial periods
• paid subscriptions
• expiry dates
• subscription status
• account access after expiry
• upgrades
• paid add-ons
• recurring billing logic

Building this made me think about the difference between simply creating a software feature and operating a product continuously.

The product has to know not just what users can do, but also what they have paid for and when that access should change.

The Biggest Product Challenge

The hardest problem with Keepur has been deciding where inventory management ends and ERP begins.

Once you build inventory, users naturally start asking for:

• accounting
• manufacturing
• raw materials
• wastage
• procurement
• supplier management
• payroll
• CRM
• e-commerce
• advanced reporting
• production management

You can very quickly end up building another Odoo.

That would be a mistake.

The difficult part has been deciding:

Which operational problems belong inside Keepur, and which should remain outside the core product?

I started thinking about Keepur as a modular system.

The core stays simple.

Businesses that need more advanced capabilities can activate additional modules rather than forcing every user to navigate an enormous application.

Product Philosophy

The principle became:

Simple businesses should get a simple product. Growing businesses should not have to leave the product when their operations become more complex.

That means Keepur needs two things simultaneously:

Simplicity

A small shop should be able to start using it without training.

Extensibility

A growing company should eventually be able to introduce more advanced workflows.

Balancing those two requirements has influenced almost every product decision.

Building for the Bangladesh Market

Keepur initially focuses heavily on the needs of local businesses.

That creates different requirements compared with designing only for Western SaaS customers.

Businesses may be:

• moving from notebooks directly to software
• unfamiliar with complex ERP terminology
• highly price-sensitive
• operating from mobile devices
• managing several shops informally
• communicating with customers mainly through phone and messaging
• expecting software to match their existing operational process

That meant I could not simply copy an international inventory product.

The workflows needed to make sense in the environment where Keepur would actually be used.

Pricing Was Part of the Product

One of the important lessons from Keepur was that pricing cannot be designed after the product is finished.

The product structure and pricing model affect each other.

For example, different businesses need different limits around:

• users
• shops
• products
• devices
• transactions
• advanced functionality

Instead of creating one expensive package, I worked on tiered plans so smaller businesses could enter at a lower price while businesses with greater operational requirements could move into higher plans.

Advanced capabilities such as serial-number tracking can also work as paid functionality rather than increasing the cost for every customer.

Getting the First Paying Customer

One of the most meaningful milestones for Keepur was getting the first paying customer.

It sounds small compared with products that have thousands of users.

But for me, it changed the project completely.

Before someone pays, you are mostly testing your own assumptions.

After someone pays, the questions become different.

Suddenly I had to think about:

• reliability
• subscription status
• customer support
• onboarding
• data integrity
• feature requests
• pricing expectations
• bug impact
• renewals

It stopped being:

"I built an inventory application."

It became:

"A business is depending on software I built."

That creates a completely different level of responsibility.

Learning From Real Usage

Real customers also expose problems that are difficult to predict during development.

A developer may care about architecture.

A business owner cares about things such as:

• Where is my stock?
• Why is this quantity incorrect?
• Can my employee use this?
• Can I add another shop?
• Can I track this exact device?
• Can I send this invoice?
• How quickly can I complete this transaction?

That feedback forced me to simplify parts of the system and prioritize operational problems over technically interesting features.

What I Actually Solved

The value of Keepur is easier to understand by looking at the operational change.

Before

Products recorded manually.

Stock tracked separately.

Employees share credentials or depend on the owner.

Invoices handled through another process.

Different shops maintain separate records.

High-value products are difficult to identify individually.

Historical changes are difficult to trace.

With Keepur

Products → Inventory → Shops → Team → Transactions → Documents → Reports

inside one connected business system.

That is the problem Keepur is trying to solve.

From Inventory Tool to Business Platform

One of the important product decisions was not to define Keepur too narrowly.

Inventory is the entry point.

But businesses ultimately care about operations.

That creates a longer-term direction where Keepur can support optional modules around areas such as:

• manufacturing
• raw-material management
• wastage
• suppliers
• purchasing
• more advanced reporting
• additional business workflows

However, these should only be introduced when they solve validated customer problems.

Adding modules simply because competitors have them would make the product heavier without necessarily making it better.

My Role

Keepur is another project where I have worked across the complete product lifecycle.

My involvement includes:

Product Strategy · Problem Discovery · UX Planning · Feature Prioritization · Frontend Development · Backend Planning · SaaS Architecture · Subscription Logic · Pricing · Customer Feedback · Product Operations · Deployment · Sales Experimentation

Because I was responsible for more than engineering, I constantly had to balance three questions:

Can we build it?

Does the customer actually need it?

Will they pay for it?

The third question is the one engineers often ignore.

Keepur forced me not to.

The Result

Keepur evolved from an inventory-management concept into a working SaaS product with real business functionality and its first paying customer.

More importantly, the product gave me direct exposure to what happens after software is shipped.

The work does not stop at deployment.

Once customers depend on the product, development becomes a continuous cycle:

Observe → Learn → Prioritize → Build → Release → Support → Repeat

That experience has had a major influence on how I now approach product development.

What Keepur Taught Me

Keepur taught me that small-business software has to respect the way people already work.

You cannot force a business to completely redesign its operations just because your database architecture looks cleaner.

At the same time, simply digitizing a bad manual process is not enough.

The real challenge is finding the balance between:

existing behaviour and better behaviour.

It also taught me one of the most important lessons of building SaaS products:

A feature only becomes valuable when it improves a real workflow.

More features do not automatically make the product better.

Sometimes the best product decision is deciding what not to build.

Closing Statement

I built Keepur to help small businesses move from scattered records and manual inventory processes into one simple operational system—without forcing them into the complexity of a traditional ERP.