I have met the same problem three times, from three completely different chairs. Once as the developer hired to solve it, once as the student sitting inside it, and once as the owner paying for it. Brightgoal is what came out the third time.
This is the long version of that story. I am writing it partly because people ask, and partly because if you are running a study library right now from a notebook and a WhatsApp group, I want you to know that the person who built your software has actually sat where you are sitting.
It started with a college and a bad assumption
In 2022, a college asked me to build software to manage their library. Books, members, issue and return, the whole thing. I said yes, and I built it.
I will be honest about what I actually did, because it matters later. The first version was dynamic in theory and hardcoded in practice. Their branch names, their categories, their rules — a lot of it was baked straight into the code, because they were the only ones who were ever going to use it. That is the kind of decision that feels efficient on day one and expensive on day ninety.
Later I went back and pulled all of it apart properly, made it genuinely configurable, and a few other colleges picked it up too. That felt like success. It was a working product with real users.
Then I watched people try to actually use it.
The bug that was never in the code
It was a desktop application. To use it, you install it. To use it on another machine, you install it there too. New computer at the front desk? Install, configure, point it at the data, hope the versions match. Someone wants to check something from home? They cannot.
Nothing was broken. Every feature worked exactly as specified. And it was still, in daily practice, a burden — because the software lived in one physical place and the people did not.
- Open it on any device, anywhere
- Nothing to install or configure
- One version, always current
- Data is backed up without anyone thinking about it
- New staff member just logs in
- Only works where it is installed
- Setup required on every device
- Versions drift apart
- Backups are somebody's job, so they don't happen
- New machine means a new migration
That was the first real lesson, and it had nothing to do with features:
Software is only as good as the number of places you can open it.
A perfect tool you cannot reach at the moment you need it loses to a mediocre one you can.
I filed that away and moved on. I assumed I was done with libraries.
Then I stopped building and started sitting in one
Some time later I moved to Punjab and joined a study library as a student. Not to research anything. I just needed a quiet, disciplined place to work for a few months.
So for two to three months I sat in one, every day, and watched it run.
Here is what I saw, and I want to be precise, because I do not think any of it came from laziness. Every single one of these was a reasonable decision made by a busy person with no better option:
- The record of who paid lived in a paper notebook. The owner wrote it down. That notebook was the single source of truth for the entire business, and it existed in exactly one copy, on one desk.
- Everything else lived in Excel and WhatsApp. Student details in a sheet, payment confirmations in chat, reminders in chat, disputes settled by scrolling back through chat.
- Every new student meant collecting the same information from scratch. Name, address, phone number, ID document, guardian's number — asked, written down, typed in. Every time, for every student, at every library they ever join.
- A seat was treated as one seat. This is the one that genuinely bothered me, and it is worth its own section.
The empty seat that was already paid for
Think about what a study library actually sells. It is not really a chair. It is a chair during a specific window of time.
A student preparing for an exam who comes in at 6 in the morning and leaves at 11 has no use for that seat in the evening. Another student who works a job and studies from 5pm to 10pm has no use for it in the morning. Those two people are not competitors for one seat. They are two separate customers for two separate products that happen to share the same piece of furniture.
But when a seat is tracked in a notebook, it is almost always allocated as one unit to one person for one month, because tracking it any other way by hand is genuinely miserable. So the morning student's seat sits empty all evening, and the library turns away the evening student for lack of space — while the room is half empty.
That is not a small inefficiency. It is the core asset of the business being under-used, permanently, and invisibly, because nothing in the system makes it visible.
Before you buy any software, including mine, go and count how many of your seats are genuinely occupied at 8am, at 2pm, and at 8pm. If those three numbers are very different, you already have spare capacity you are paying rent on.
If you want the deeper version of this argument with the operational trade-offs, I wrote about it separately in the 4-slot system.
Then I owned one
Reading about a problem and paying for it are different experiences.
I ran a study library myself for two months, and every single thing I had calmly observed as a student arrived on my desk as my responsibility. Who has paid. Who is due. Who left. Which seat is free at 4pm. Which student is the one asking for a refund and what did they actually pay. Where is that number written down.
Two months is not a long time. It was long enough.
I tried the spreadsheet first, and it did not survive
I want this part in the story, because it is the part that usually gets edited out.
My first instinct was not to build a product. It was to build a really good spreadsheet. I know how to do that. Formulas for pro-rata, a tab per month, conditional formatting for who is overdue. It worked. For a while, it genuinely worked.
Then the month rolled over, and the structure needed rebuilding. Then a student changed slots halfway through a cycle and the formulas quietly produced a wrong number. Then I needed last quarter's history and the tab it lived in had been overwritten.
A spreadsheet can hold a library for a month. Maybe, with real discipline, a year. But it does not accumulate. Every cycle you pay the setup cost again, and the errors are silent — a spreadsheet never tells you it just gave you the wrong refund.
Spreadsheets do not break loudly. They keep producing numbers that look completely reasonable and are wrong, and you find out weeks later during an argument with a student about money.
That was the moment the decision actually got made. Not "wouldn't it be nice if". More like: this problem is real, it is repeating, I have hit it from three directions, and I already know how to build the thing.
What I decided to build, and why it looks the way it does
Every early decision came straight out of those three experiences.
- 1
Web first, permanently
Because of the college desktop app. The owner should be able to open their library from the front desk, from home, from a phone on a train, without installing anything or thinking about which device has the real data.
- 2
Seats sold by time window, not by month
Because of the empty evening seat. One physical seat can carry several students in different slots, and the system should make that obvious and safe rather than leaving it to memory.
- 3
The owner never thinks about the database
Because backups only happen when they are nobody's job. No installs, no migrations, no "which laptop has the file".
- 4
Staff, with limits
Because an owner who cannot delegate has not been given a tool, they have been given a second job. Staff can be added with exactly the permissions they should have, and those limits are enforced on the server, not just hidden in the interface.
- 5
Built for more than one country from the start
Because the document a student proves their identity with is an Aadhaar card in India and something entirely different elsewhere. Currency, phone format, address fields and ID type all follow the library's country instead of assuming everyone is in the same place.
The part I am most proud of: the second time should be free
This one came directly from watching students get interrogated at a front desk for the third time in a year.
A student's identity does not change when they walk into a different library. Their name, their document number, their phone number — that is the same person. Only the enrollment is new.
So a student's record in Brightgoal is keyed to their identity document, and it belongs to the student, not to any single library. The first time someone is enrolled anywhere, their details get captured once. After that, at any library on the platform, the owner types the document number and the student's information is already there. What is left to decide is genuinely new information: which seat, which slot, and whether they want a locker.
The first enrollment costs a few minutes. Every one after it should cost seconds — and the longer the platform runs, the more often it is the second kind.
What Brightgoal is today
Everything in this list exists right now. I am deliberately not listing anything that does not:
- Seats, slots, lockers, students, payments and staff, managed from one dashboard
- One account holding several libraries, each fully separated from the others
- Automatic pro-rata maths for mid-cycle changes — slot changes, cancellations, refunds, lockers added halfway through a month
- A public website for every library at
brightgoal.in/yourname, where students can see slots, hours, photos and facilities, get directions, and send an enquiry with a live price estimate - A dashboard that is fully usable on a phone and installable as an app, without an app store
- The interface itself in English, Hindi or Punjabi, while billing and validation still follow each library's own country
What is not built yet
I would rather write this section than have you discover the gaps yourself.
Verified student records. Today, student details are typed in by the library owner, which means they are exactly as accurate as whoever entered them. I intend to add verification against official records, so a document number confirms the person behind it and the details stop depending on careful typing. That work has not shipped. When it does, I will write about it here.
A native mobile app. The dashboard already works properly on a phone and installs as an app, which covers most of the need. A true native app running on the same API is on the list, but it is not a promise with a date attached.
If a feature is not in the list above, assume it does not exist yet. I would rather lose a signup than win one on something I have not built.
If you are the person I was
If you are running a study library out of a notebook and a WhatsApp group right now, I do not think you are disorganised. I think you are doing something genuinely hard with tools that were never designed for it, and I think you already know exactly which parts hurt — the renewals you forgot, the refund you calculated twice and got two answers, the seat you know is empty but cannot prove.
I built this because I sat in that chair, and because I tried the cheap fix first and watched it fall over.
You can start free, without a card, and set up your first library in a few minutes. If something in it annoys you, my email is on this page and it comes to me directly.
We did the maths on what manual record-keeping actually costs a library each month.
Start where I should have started.
Set up your library free, with no card — and skip the spreadsheet year entirely.





