<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Kuwa Advisory Notes</title>
    <link>https://kuwaadvisory.com/notes/</link>
    <atom:link href="https://kuwaadvisory.com/notes/feed.xml" rel="self" type="application/rss+xml"/>
    <description>Field notes on building operational systems for lenders, schools and design practices in Africa.</description>
    <language>en-gb</language>
    <lastBuildDate>Fri, 02 Oct 2026 00:00:00 GMT</lastBuildDate>
    <item>
      <title>The loss you find at the final account</title>
      <link>https://kuwaadvisory.com/notes/architecture-project-profitability/</link>
      <guid isPermaLink="true">https://kuwaadvisory.com/notes/architecture-project-profitability/</guid>
      <pubDate>Fri, 02 Oct 2026 00:00:00 GMT</pubDate>
      <description>A busy, respected practice can still lose money on half its projects. Project profitability you can see in time: billable versus cost rate per employee.</description>
      <content:encoded><![CDATA[<p><em>Why a busy, respected firm can still run out of money, and why it only finds out when it is too late to act.</em></p>
<p>The principal of a Lagos architecture firm told me about the worst kind of surprise.</p>
<p>Not a lost bid. Not a client walking away. A project everyone had felt good about, delivered, closed, and then, at the final account, the numbers came in and it had lost money. Not a little. Enough to matter. And the thing that stayed with him was not the loss itself. It was that he had no way of knowing until it was over. By the time the number arrived, there was nothing left to do about it.</p>
<p>This is the quiet killer in an architecture practice. Not bad design. Not a shortage of work. A firm can be busy, respected, and admired, with good projects going out the door, and still be bleeding money on half of them without anyone able to see it happening.</p>
<p>Here is why the bleeding is invisible.</p>
<h2>A fee that is fixed, and effort that is not</h2>
<p>An architecture firm agrees its fee near the start of a project, often as a percentage of the construction value. That number is fixed. The client is not going to pay more because the design took longer.</p>
<p>But the effort is not fixed at all. The hours poured into a project rise and fall with revisions, with a difficult client, with a stage that turned out harder than expected. And in most firms, nobody is measuring those hours against the fee while the work is happening. Timesheets are filled in late, or not at all. The fee lives in a proposal document. The hours live in people's heads. The two never meet until the project is closed and someone finally does the sum.</p>
<p>By then the story is already written. The firm did the work, spent the hours, and the fee was whatever it was. The loss is a historical fact, not a decision anyone got to make.</p>
<h2>What it looks like to see it in time</h2>
<p>Now picture the same firm with one difference. Every person logs their hours against a project and a stage as they work. Every person carries two numbers: what the firm bills for their time, and what that time costs the firm. The gap between those two numbers, across everyone on a project, is the project's real margin, visible today, not at the final account.</p>
<p>This changes what a principal can do. Suppose the developed-design stage was budgeted at 200 hours and has already burned 280, with the deliverables not yet finished. In the old world, that fact surfaces at the end, as a loss. In this world it surfaces now, as a warning, while there is still a next stage to reprice, a scope conversation to have, or a decision to staff the work differently. The firm acts on the project instead of reading its obituary.</p>
<p>Go the other way and the same numbers answer a different question: which people, doing which kinds of work, generate the most value per billable hour. Not who works the most hours. Who earns the firm the most for the time they spend. For a principal deciding who to put on the next important project, that is a real signal, and it was sitting in the timesheets all along.</p>
<p>None of this is exotic accounting. It is the ordinary discipline of knowing your cost and your price at the same time. Most firms simply have no place to put it.</p>
<h2>Why the usual software has no place to put it</h2>
<p>Here is the deeper reason. Business software is mostly built for companies that sell things. It has a natural idea of a product, a stock level, a purchase of materials, a sale of goods. An architecture firm does almost none of that. It sells professional time and judgement, and it administers contracts between a client and a builder.</p>
<p>The objects that matter in a practice, the fee agreed as a percentage of construction value, the quantity surveyor as a role, the interim payment certificate, the variation register, do not exist in a system built for selling widgets. So the profitability view a firm needs is not a report you switch on. It has to be built, on top of a system flexible enough to hold objects it did not ship with. ERPNext, the open-source business platform, can hold them, because it lets you add the objects a practice actually runs on. That is the difference between software that tolerates an architecture firm and software that fits one.</p>
<h2>The insight</h2>
<p>A design firm rarely dies of bad design. It dies of not knowing, in time, which of its projects are quietly losing money. The fee is agreed once, near the beginning, when everyone is optimistic. The hours accumulate slowly, in a hundred small revisions nobody is counting. And the two numbers only meet at the final account, when the meeting is a post-mortem.</p>
<p>The firms that stay healthy are not the ones that never have a bad project. Every firm has bad projects. They are the ones that can see a project going bad while it is still going, so that the loss they find at the final account is one they chose to accept, not one that was waiting for them all along.</p>
]]></content:encoded>
    </item>
    <item>
      <title>Further behind than she really is</title>
      <link>https://kuwaadvisory.com/notes/icce-credit-tracking-across-years/</link>
      <guid isPermaLink="true">https://kuwaadvisory.com/notes/icce-credit-tracking-across-years/</guid>
      <pubDate>Fri, 02 Oct 2026 00:00:00 GMT</pubDate>
      <description>The most common mistake in ACE schools is counting credits per year. Why ICCE certificate progress must aggregate across years, not within one.</description>
      <content:encoded><![CDATA[<p><em>The single most common mistake in tracking self-paced students, and why it makes a school tell a family a lie without meaning to.</em></p>
<p>Imagine a parent sitting across from a school administrator, being told their daughter has fallen behind. She has earned only one credit this year. The parent's face falls. They had thought she was doing well. Now they are told she is near the bottom.</p>
<p>The number is real. The report is honest. And it is completely wrong. The girl has not earned one credit. She has earned four. The report only counted this year, and in this kind of school, counting only this year is the most common and most damaging mistake there is.</p>
<h2>Why a year is the wrong window</h2>
<p>This is an Accelerated Christian Education school, where children work through workbooks at their own pace and build up credits toward certificates over time. The certificates are the milestones that matter. And here is the crucial fact: a certificate is earned across academic years, not within one.</p>
<p>A single certificate might span two full years of work. A child chips away at it, workbook by workbook, credit by credit, across that whole span. At any moment, some of the credits she has earned toward it were earned last year, and some this year. That is not a problem. That is simply how the curriculum works.</p>
<p>So when you ask how far along a child is, the honest answer has to gather every credit she has ever earned toward that certificate, whenever she earned it. Gather only this year's, and you have not measured her progress. You have measured the last twelve months and thrown away everything before them.</p>
<h2>What the mistake does to a family</h2>
<p>Picture what the wrong window does in that meeting.</p>
<p>The girl earned three credits last year and one this year. Four in total, real progress toward a certificate that spans two years. But the report was scoped to the current year, so it counted one. To the administrator reading it, she looks stalled. To the parent hearing it, she looks like she is failing. A conversation that should have been about what comes next becomes a conversation about whether the child is in trouble.</p>
<p>The damage is not only to the mood in the room. Decisions get made on that number. A child who looks stalled might be pulled from an activity, or pushed into remedial work she does not need, or simply carry the quiet weight of a parent who now believes she is struggling. All of it flows from a report that dropped last year's work on the floor.</p>
<p>And it cuts the other way too. Scope the window wrong in the other direction, or double-count across years, and a child can be made to look further ahead than she is, so that a certificate everyone believed was almost finished turns out to be months away. Either way, the school is now steering by a false instrument.</p>
<h2>Getting the window right</h2>
<p>The fix is not clever. It is disciplined. Every measure of a child's progress toward a certificate must aggregate across academic years, gathering the full set of credits earned toward it, from the first day the child started working toward it to today. Never per term. Never per year. Across the whole life of the certificate.</p>
<p>This is easy to state and easy to get wrong, because most systems are built to think in years. A school year is the natural unit almost everywhere else: one intake, one set of exams, one report card, then reset. An ACE school does not reset. The child carries their progress forward, and the system has to carry it forward with them. A report that quietly resets at the year boundary will look completely normal and will be wrong for every child whose certificate spans more than one year, which is most of them.</p>
<p>When it is done right, the payoff is quiet but large. A child's real position is visible at any moment: everything earned, whenever it was earned, counted once and counted correctly. The meeting with the parent starts from the truth. And the truth, in the case of the girl who looked stalled, was that she had earned four credits, not one, and was exactly where she should be.</p>
<h2>The insight</h2>
<p>The most dangerous errors in a school are not the ones that lose data. They are the ones that measure it against the wrong frame. Nobody lost the girl's earlier credits. They were all there, recorded, correct. The system simply refused to look at them, because it was built to see one year at a time.</p>
<p>A self-paced school lives across years, not within them. Any number that describes a child's progress has to live across years too, or it will keep telling families a version of their child that is not true. Getting the window right is not a technical nicety. It is the difference between a school that tells parents the truth about their children and one that, with the best of intentions and clean-looking reports, quietly does not.</p>
]]></content:encoded>
    </item>
    <item>
      <title>The lender with no borrowers</title>
      <link>https://kuwaadvisory.com/notes/launching-a-lender-from-zero/</link>
      <guid isPermaLink="true">https://kuwaadvisory.com/notes/launching-a-lender-from-zero/</guid>
      <pubDate>Fri, 02 Oct 2026 00:00:00 GMT</pubDate>
      <description>Starting a loan book from zero is an advantage, not a handicap. Why a new lender can build clean and bake in regulatory reporting from day one.</description>
      <content:encoded><![CDATA[<p><em>Why starting a loan book from nothing is an advantage, not a handicap.</em></p>
<p>Before a lender writes its first loan, there is a strange, quiet moment. The company exists. The facility is arranged. The office is rented. And the loan book is completely empty. No borrowers. No repayments. No history.</p>
<p>Most people treat that emptiness as a weakness. A new lender with no track record, nothing to show. In a software project, the emptiness looks worse still, because the thing that usually makes a business system worth having is data, and here there is none to bring across.</p>
<p>That reading is backwards. For a lender, an empty book is the best starting position you will ever have.</p>
<p>Here is why.</p>
<h2>The expensive part is the book you already have</h2>
<p>Ask anyone who has moved a working lender onto a new system what the hard part was. It was never the software. It was the history.</p>
<p>A lender that has run for three years in spreadsheets has three years of loans in flight. Some are current. Some are late. Some were restructured once and quietly forgotten. Some customers appear twice under slightly different names. The interest was worked out one way in one year and another way the next. Nobody can say with certainty what the total outstanding actually is, because the number depends on which spreadsheet you believe.</p>
<p>Moving that onto a clean system means untangling every one of those threads first. What is the real balance on this loan. Which of these two rows is the same person. Was this repayment ever actually received. The work is slow and painful, and it is expensive precisely because the answers are no longer knowable. Garbage in, garbage out is not a slogan here. It is the invoice.</p>
<p>A lender with no borrowers has none of that. There is nothing to untangle, because nothing is tangled yet.</p>
<h2>What you build in the empty room</h2>
<p>The empty book is not only an absence. It is a chance to set the rules before a single loan tests them.</p>
<p>You define the loan products cleanly: the term, the way interest is charged, the fees, once, correctly, so every loan that follows inherits the same logic. You build the chart of accounts, the master list of financial buckets a business records money into, so that the very first payout lands in the right place. You decide how a repayment schedule is produced and let the system produce it, instead of a person typing dates into a sheet.</p>
<p>And you set up the field structure before there is a field. The agents who will take cash and move it over mobile money are defined in the system before they are hired, so the day the first agent starts, the system already knows how their collections should flow and check out against the book.</p>
<p>None of this is glamorous. All of it is close to impossible to do cleanly once real money is running through it.</p>
<h2>Building the regulator in from the first day</h2>
<p>There is one more thing an empty book lets you do, and it is the one that will matter most.</p>
<p>The Bank of Ghana is reclassifying the smallest formal lenders, Tier 4 non-deposit-taking micro-credit enterprises, under a new category called Last-Mile Providers, in notice BG/GOV/SEC/2026/03. Lenders who have run for years will have to bend their existing records to fit the new reporting shape. That is a retrofit, and retrofits leak.</p>
<p>A lender launching now does not retrofit anything. The category the regulator cares about can be built into the loan book as a dimension from the first loan, so that the report the regulator will one day ask for is not a special project. It is a button. The reclassification that will cost an established lender weeks costs a new one nothing, because the new one never built the wrong shape to begin with.</p>
<p>This is the quiet gift of starting with nothing. Every established lender is carrying the cost of decisions made before the rules were clear. A lender launching today gets to make those same decisions after.</p>
<p>The most expensive part of any lending system is the book you already have. A founder with no borrowers has, for one short window, no expensive part at all. The only history that book will ever carry is the clean one they are about to write. That window closes the moment the first loan goes out. What you put into the empty room now is what the business will stand on for years.</p>
]]></content:encoded>
    </item>
    <item>
      <title>The number the phone says and the number the book says</title>
      <link>https://kuwaadvisory.com/notes/mobile-money-loan-book-reconciliation/</link>
      <guid isPermaLink="true">https://kuwaadvisory.com/notes/mobile-money-loan-book-reconciliation/</guid>
      <pubDate>Fri, 02 Oct 2026 00:00:00 GMT</pubDate>
      <description>Why the hardest part of running an African micro-lender is the gap between mobile money and the loan book, and what closing it actually takes.</description>
      <content:encoded><![CDATA[<p><em>The reconciliation gap between mobile money and the loan book, and why it quietly decides which African micro-lenders survive their first year.</em></p>
<p>A lender in Accra was three days from opening, and he could not sleep.</p>
<p>It was not the money. He had a facility lined up, a small team, an office. The product was simple: short loans to traders and small shops, paid out and collected in the field, all of it moving over mobile money. He had run the numbers a hundred times.</p>
<p>What kept him awake was a smaller thing. In three days, his field agents would start taking cash from customers and paying loans out from their phones. Every one of those movements would land in a mobile money wallet before it ever reached a book. And he had no way, on any given morning, to know whether the number on an agent's phone matched the number in his records.</p>
<p>He put it plainly. &quot;The day those two numbers disagree, how do I know which one is lying?&quot;</p>
<p>That question is the whole business.</p>
<p>Most people think the hard part of lending is the lending. Deciding who to trust. Setting the rate. Chasing repayment. Those are hard. But they are not the part that quietly kills a young lender. The part that kills a young lender is the gap between what the money is actually doing out in the field and what the book says it is doing. Close that gap and everything else is manageable. Leave it open and the book turns into fiction, one small drift at a time.</p>
<h2>Where the gap opens</h2>
<p>Follow a single repayment.</p>
<p>A customer hands 200 cedis in cash to an agent standing in a market. The agent has the cash. Good. Now that cash has to become a record. The agent pushes it into a mobile money wallet. That is one hop. The money then moves from the agent's wallet toward the lender's collection account. That is a second hop. Inside the lender's system, that payment has to be matched to a specific loan, on a specific repayment schedule, for a specific customer. That is a third hop.</p>
<p>Every hop is a place the number can drift. The agent banks 180 and keeps the rest. A transfer fails halfway and nobody notices for a day. Two customers pay the same amount within a minute of each other, and the payment is matched to the wrong loan. None of this is exotic. All of it happens. And each time, a small space opens between the money and the book.</p>
<p>A spreadsheet cannot hold this. Not because a spreadsheet is weak, but because the job needs one place that knows three things at the same moment: that the loan was paid out, that the repayment came in, and that the two belong to the same schedule. A spreadsheet knows only what the last person typed into it. It does not watch the mobile money account. It does not raise its hand when a payment arrives with no loan to match. It cannot tell you, at nine in the morning, where the money is right now.</p>
<p>That is the real reason a lender outgrows a spreadsheet. Not volume. Truth.</p>
<p>What closes the gap is one system holding the loan book and the money movement together, so the phone and the book stop being two separate stories and become one story that checks itself every time money moves. The payout is recorded against a loan. The repayment schedule is generated from that loan. The mobile money payment, when it lands, is matched against that schedule as it arrives, so a payment with no loan behind it is caught the moment it appears instead of at the end of the month. This is what ERPNext with Frappe Lending does for a lender at this size. ERPNext is the open-source system that runs the accounts and the operations, and Frappe Lending is the part built on top of it that understands loans, schedules and interest.</p>
<h2>Why it matters more now</h2>
<p>There was a second reason the founder could not sleep, and this one was not in his hands at all.</p>
<p>The Bank of Ghana has been redrawing the map for lenders like him. Under notice BG/GOV/SEC/2026/03, Tier 4 non-deposit-taking micro-credit enterprises, the smallest formal class of lender, are being brought under a new heading: Last-Mile Providers. The fine detail is still settling. The direction is not in doubt. More lenders, sorted more clearly into categories, expected more clearly to report what they are doing.</p>
<p>Here is what that means on a Tuesday morning. A lender who cannot reconcile cannot report. If your book and your money do not agree, you cannot produce a return you would put your name to, and a return you would not put your name to is worse than none at all. The lenders who will struggle under the new rules are not the ones with the wrong product. They are the ones who built on a foundation that could never answer one plain question: where is the money right now.</p>
<p>The founder in Accra saw this before the regulator made him. That is why he could not sleep three days out. Not because the lending was hard, but because he knew that on the first morning the phone and the book disagreed, &quot;let me get back to you&quot; would not be an answer he could afford to give.</p>
<p>The lenders who survive their first year are not the ones with the cleverest credit model. They are the ones who, on any morning, for any loan, could tell you exactly where the money was. Everything else in lending is a decision you can revisit. That one is a foundation you either poured straight, or you did not.</p>
]]></content:encoded>
    </item>
    <item>
      <title>The second investor you do not have yet</title>
      <link>https://kuwaadvisory.com/notes/multi-investor-loan-allocation/</link>
      <guid isPermaLink="true">https://kuwaadvisory.com/notes/multi-investor-loan-allocation/</guid>
      <pubDate>Fri, 02 Oct 2026 00:00:00 GMT</pubDate>
      <description>When a second investor funds the same loan book, every repayment has to reach the right pool. Why to build for that before the second cheque clears.</description>
      <content:encoded><![CDATA[<p><em>Why the time to build for a second funder is before the first repayment, not after the second cheque.</em></p>
<p>Right now, one investor funds the whole book.</p>
<p>It is a common way for a small lender to start. A single facility, one pool of money, and every loan the lender writes is, in effect, that investor's money at work. The accounting is simple, because there is nothing to divide. Money comes in from one source, goes out as loans, comes back as repayments. One story, one owner.</p>
<p>Then the lender grows, which is the whole point. A second investor appears. Maybe a third. And on the day the second cheque clears, the simple story quietly becomes a hard one.</p>
<h2>The day the money has more than one owner</h2>
<p>The moment a second facility funds the same book, every number in the business has to answer a new question: whose money is this?</p>
<p>When the lender pays out a loan, which investor's pool did it come from? When a customer repays, whose principal is being returned and whose interest is being earned? When a loan goes bad, whose loss is it? Each investor put money in on their own terms, expecting their own share of the return and carrying their own share of the risk. The book now has to keep those shares straight, loan by loan, repayment by repayment, for as long as the money is in play.</p>
<p>A system built for one investor has nowhere to put that question. Every loan was implicitly the one investor's, so nothing tags a loan to a source. Nothing splits a repayment. Nothing apportions interest or loss. To add a second investor, the lender has to reach into a live book, full of loans in flight, and rebuild how it tracks money while money is still moving through it. That is open-heart surgery on a running business.</p>
<h2>What building it early actually means</h2>
<p>The founder in Accra had only one facility. He asked for the second-investor logic anyway, before there was a second investor.</p>
<p>That instinct is the right one, and it costs almost nothing to act on while the book is empty or small. It means that from the first loan, every payout carries a tag for which funding source paid for it. Every repayment splits automatically along that tag, principal and interest routed to the right pool. Every default is charged to the pool that funded it. And a statement showing exactly what each funder's money did is a report the system can already produce, because the information was captured all along instead of reconstructed later.</p>
<p>Built this way, the second investor is not an event. It is a new row in a list of funding sources. The book already knew how to keep money separate. It had simply, until now, been keeping one pile separate from nothing.</p>
<h2>The cost of waiting, in one comparison</h2>
<p>Here is the whole argument side by side.</p>
<p>The cheapest time to build for the second investor is before there is a single repayment to allocate, when the change is a design decision and touches no live money. The most expensive time is the morning the second investor's money lands and you find the book cannot tell whose money did what, so you rebuild it under load, with real loans, real repayments, and now two people watching who both believe the returns are theirs.</p>
<p>Growth is supposed to be the good problem. It only stays a good problem if the system was built to survive it. A lender who plans for the second investor while still living off the first is not being premature. They are buying, for almost nothing today, the one thing that is ruinously expensive to buy later: a book that always knows whose money did what.</p>
]]></content:encoded>
    </item>
    <item>
      <title>The workbook that was not on the shelf</title>
      <link>https://kuwaadvisory.com/notes/pace-inventory-replenishment-ace-schools/</link>
      <guid isPermaLink="true">https://kuwaadvisory.com/notes/pace-inventory-replenishment-ace-schools/</guid>
      <pubDate>Fri, 02 Oct 2026 00:00:00 GMT</pubDate>
      <description>In a self-paced school the store cupboard is the real bottleneck. How demand-driven replenishment keeps each child&#39;s next PACE workbook on the shelf.</description>
      <content:encoded><![CDATA[<p><em>Why the store cupboard is an operations problem, not a stationery one, and how a missing workbook quietly stops a child from learning.</em></p>
<p>A child finishes a workbook, passes the test, and is ready for the next one. She walks to the store to collect it. It is not there. The school has run out.</p>
<p>So she waits. A day, maybe a week, until the next order comes in. She is willing, she is ready, and she is stopped, not by anything about her, but by an empty shelf. Multiply that by a school full of children each moving at their own speed, and the empty shelf stops being a small inconvenience. It becomes the single most common reason a child who wants to learn cannot.</p>
<p>Most schools treat the store cupboard as a stationery matter. Someone notices things are running low and puts in an order. In a self-paced school, that casual approach quietly fails, and it fails for a reason worth understanding.</p>
<h2>Why the ordinary way of ordering breaks</h2>
<p>In an ordinary school, demand is predictable. Everyone in a class needs the same book at the same time. You count the class, you order that many, you are done.</p>
<p>In an Accelerated Christian Education school, every child is on a different workbook. There is no class needing the same thing at once. There are sixty children, each about to need a different next workbook, on a schedule only they control. What the store needs next week depends on exactly where each child is this week and how fast each is moving. A person eyeballing the shelves cannot hold sixty separate trajectories in their head. So they order too much of what is not needed and too little of what is, and children keep hitting empty shelves anyway.</p>
<p>The usual fix, a reorder level, does not solve it either. A reorder level says: when this drops below ten, buy more. But it has no idea who is about to need this specific workbook, or that a child three shelves over is one test away from needing something the store does not stock at all. It reacts to the past. In a self-paced school the useful question is about the near future: given where every child actually is, what will they each reach for next?</p>
<h2>Ordering from where the children actually are</h2>
<p>The better way starts from the children, not the shelves.</p>
<p>For each child, the system looks at the workbook they are on and the next few they are about to need, a short window ahead of their current position. It does this for every child, then adds it all up: this is what the school will actually need in the coming weeks, workbook by workbook. It subtracts what is already on the shelf, and it subtracts what is already on order, so it never asks for something that is on its way. Then it drafts an order sized to exactly the gap, no more.</p>
<p>The effect is quiet and important. The order is no longer a guess. It is a projection built from where every child genuinely is. If a workbook is already coming, the system stays its hand rather than over-ordering, which is something no eyeballed count and no simple reorder level can do. And the child who was about to hit an empty shelf finds the workbook waiting instead, because the store saw her coming.</p>
<h2>The store is where learning stops or continues</h2>
<p>It is easy to think of the store as the back office of a school, a long way from the real work of teaching. In a self-paced school it is the opposite. The store is where learning either continues or stops.</p>
<p>A child in this model is never held back by the pace of a class, because there is no class. The only thing that can stop a ready child is not having the next workbook in hand. That makes the store cupboard one of the most academically important rooms in the building. A well-run store is invisible: children always have what they need next, and nobody thinks about it. A badly run store is a series of small, quiet halts, each one a willing child sitting idle, each one invisible in any report that does not think to look.</p>
<h2>The insight</h2>
<p>The deepest operational truth of a self-paced school is that its bottleneck is physical. Not motivation, not teaching, not curriculum. A workbook on a shelf, or not on a shelf. The child is ready. The only question is whether the next thing she needs is there when she reaches for it.</p>
<p>Solve that, and you have removed the one obstacle a self-paced school uniquely creates. Ignore it, and the most self-motivated child in the school will still be stopped, again and again, by a cupboard nobody was watching closely enough. The store is not stationery. It is the place where a child's momentum is either kept or lost.</p>
]]></content:encoded>
    </item>
    <item>
      <title>The boy the system marked complete</title>
      <link>https://kuwaadvisory.com/notes/software-for-ace-self-paced-schools/</link>
      <guid isPermaLink="true">https://kuwaadvisory.com/notes/software-for-ace-self-paced-schools/</guid>
      <pubDate>Fri, 02 Oct 2026 00:00:00 GMT</pubDate>
      <description>Software built for a class of thirty breaks where every child is on a different PACE workbook. Why an ACE school must track the child, not the number.</description>
      <content:encoded><![CDATA[<p><em>Why software built for a class of thirty quietly breaks in a school where sixty children are each on a different workbook.</em></p>
<p>There is a boy in a school in Uganda, in what most systems would call Grade 9, whose record said he had completed Mathematics and Science.</p>
<p>He had not. He had finished the Grade 1 workbooks in those subjects and gone no further. The record was not lying on purpose. It had been built by software that did exactly what it was told, and what it was told was wrong at the root. To understand how a fourteen-year-old ends up marked complete at the level of a six-year-old, you have to understand what kind of school this is, because it is not the kind almost all school software was built for.</p>
<h2>A different kind of school</h2>
<p>This is an Accelerated Christian Education school, an ACE school. Children do not move together through a syllabus. Each child works alone through a series of workbooks, called PACEs, at their own speed. You finish a PACE when you can pass its test at eighty percent. You move to the next one when you are ready, not when the term ends. Credits build up, PACE by PACE, toward certificates. There is no class of thirty on the same page on the same day. There are sixty children, each on a different page, each on a different day.</p>
<p>Now hold that next to how ordinary school software thinks. It assumes a grade. It assumes a timetable. It assumes that if you are in Grade 9, you are doing Grade 9 work, and that the whole class is roughly together. Every one of those assumptions is false in an ACE school. And when a piece of software is built on assumptions that are false, it does not break loudly. It breaks quietly, and it keeps producing numbers that look fine.</p>
<h2>How the number lied</h2>
<p>Here is the specific trap that caught the boy.</p>
<p>In this curriculum, the workbooks are numbered, and the numbers restart at each grade. The Grade 1 mathematics workbooks might run one through twelve, and so might the Grade 2 workbooks, and the Grade 3, all the way up the school. Worse, across subjects the same numbers repeat: the Algebra workbook, the Biology workbook, and the English workbook can all carry the identical number, because the number is a position within a grade band, not a name for a unique booklet.</p>
<p>So the number, on its own, means almost nothing. It cannot tell you the grade. It cannot even tell you the subject. It only means something when you already know which child, which subject, and which grade you are looking at.</p>
<p>A system that follows the number instead of the child walks straight off a cliff. The boy had finished workbook twelve in Mathematics. The software looked for workbook thirteen, found none, because the numbers restart, and concluded he had reached the end. It marked him complete. He had reached the end of Grade 1, not the end of Mathematics. The number said twelve. The software believed the number. The child was lost inside it.</p>
<h2>Track the child, not the number</h2>
<p>The lesson underneath this is simple to say and easy to get wrong. In a self-paced school, you must track the child, not the number.</p>
<p>That means the system must always carry the full context with every record: this child, this subject, this grade band, this position within it. It must never read a bare workbook number and infer anything from it, because the number carries no meaning on its own. It must know that finishing the twelfth workbook of Grade 1 is not finishing the subject, and it must know this for every child independently, because no two children are in the same place.</p>
<p>This sounds obvious once it is said. It is anything but obvious when you are configuring software that was built, deep in its bones, to assume a class moving together. The assumption hides. It does not announce itself. It surfaces months later, as a boy marked complete when he has barely begun, or as a report that quietly tells a family the wrong thing about their child.</p>
<h2>The insight</h2>
<p>Software does not have to be broken to be wrong. The boy's record ran without error. Every function did what it was written to do. The wrongness was upstream of the code, in an assumption that a number could stand in for a child.</p>
<p>A school that runs on self-paced learning is not a normal school with a few unusual features. It is a different machine, and it needs software built around its actual unit, which is one child and one workbook, not thirty children and one lesson. Force it into software built for the ordinary case and it will run, produce clean-looking numbers, and slowly lie to you about the children it exists to serve. The most dangerous report is not the one that shows an error. It is the one that looks perfectly fine and is telling you a fourteen-year-old finished mathematics when he finished the first year of it.</p>
]]></content:encoded>
    </item>
    <item>
      <title>The variation nobody wrote down</title>
      <link>https://kuwaadvisory.com/notes/variation-register-architecture-firms/</link>
      <guid isPermaLink="true">https://kuwaadvisory.com/notes/variation-register-architecture-firms/</guid>
      <pubDate>Fri, 02 Oct 2026 00:00:00 GMT</pubDate>
      <description>Variations agreed verbally on site become disputes months later. Why a variation register protects a firm&#39;s money and its professional standing.</description>
      <content:encoded><![CDATA[<p><em>Why the change agreed in a five-minute site conversation is the one most likely to cost the firm money and standing.</em></p>
<p>Every project has a moment like this. The team is on site. The client, or the client's representative, points at something and asks for a change. Move the wall. Upgrade the finish. Add the extra room. Everyone nods. Work continues. And nobody writes it down.</p>
<p>Three months later, the change has been built, the cost has been spent, and the question arrives: who agreed to this, and who is paying for it? The client remembers a casual conversation. The firm remembers a clear instruction. The builder remembers doing the work. And there is no document that settles it. The change that took thirty seconds to agree becomes a dispute that takes months to resolve, and often the firm eats the cost rather than damage the relationship.</p>
<p>This is not a small leak. On a large project, the variations, the changes to the original scope, can add up to a serious fraction of the whole. And they are precisely the part of the work most likely to be undocumented, because they are agreed in the flow of the job rather than in the calm of a signed contract.</p>
<h2>Why the change is the dangerous part</h2>
<p>The original contract is the easy part to control. It is written, priced, and signed. Everyone knows what it says.</p>
<p>The variation is the opposite. It is born in a conversation, often on site, often verbally, often under time pressure. It changes the scope, which means it changes the cost and the programme. And because it is a change, it sits outside the tidy world of the signed contract, in the messy world of what people actually said to each other on a Tuesday. That is exactly why it is dangerous. The money is real, the liability is real, and the record is a memory.</p>
<p>For an architecture or quantity surveying firm, this is not only a money problem. It is a professional standing problem. The firm's instructions carry weight. When the firm issues a change, or certifies a payment for work done, it is acting in a role that a body like the Architects Registration Council of Nigeria, ARCON, and the Nigerian Institute of Architects, the NIA, hold members accountable for. A firm whose instructions and certifications live only in memory and WhatsApp is exposed twice: financially, when the cost is disputed, and professionally, when it cannot show the record behind a decision it is answerable for.</p>
<h2>What a record that stands looks like</h2>
<p>The fix is not complicated in idea. Every change gets written down the moment it is agreed, in a place built to hold it.</p>
<p>That place is a variation register: a running record of every change to the original scope. Each entry names what changed, who instructed it, what it is expected to cost, and where it stands, from raised, to priced by the quantity surveyor, to approved, to rejected. The verbal instruction on site becomes an architect's instruction with a date and an author. The cost consequence is captured while it is still an estimate someone can argue about, not a bill nobody can trace.</p>
<p>The same discipline runs through the money side of a build. When a builder claims payment, the claim comes in as a payment application. The quantity surveyor assesses it. The firm issues an interim payment certificate, the certified statement of what is actually due for work actually done, linked to the application it answers. Every step is a record with an author and a date. The result is that the answer to &quot;who agreed to this, and who is paying for it&quot; is never a memory. It is a document.</p>
<h2>The insight</h2>
<p>The riskiest work on any project is the work that happens off the contract. The signed agreement takes care of itself. It is the change agreed in a corridor, the upgrade promised on site, the extra floor added by a nod, that quietly turns into unpaid work and, worse, into a dispute where the firm cannot show what it agreed and why.</p>
<p>A firm that records its variations is not being bureaucratic. It is protecting the two things it cannot afford to lose: the money on the project, and the professional standing that comes from being able to show, at any time, exactly what it instructed and exactly why. The thirty-second change deserves a thirty-second record. The firms that learn this the hard way learn it at the final account, or in a room they did not want to be in, explaining a decision they can no longer prove they made.</p>
]]></content:encoded>
    </item>
    <item>
      <title>Why the last ERP failed</title>
      <link>https://kuwaadvisory.com/notes/why-erp-fails-architecture-firms/</link>
      <guid isPermaLink="true">https://kuwaadvisory.com/notes/why-erp-fails-architecture-firms/</guid>
      <pubDate>Fri, 02 Oct 2026 00:00:00 GMT</pubDate>
      <description>The real reason a firm&#39;s first ERP failed is rarely capability. It is per-seat pricing and forcing a practice into software built for selling products.</description>
      <content:encoded><![CDATA[<p><em>The real reason a firm's first attempt at proper software collapsed, and why it was not the reason everyone remembers.</em></p>
<p>When I first spoke with a high-rise practice in Lagos about their operations, the first thing that came up was not what they wanted. It was what they had already been through.</p>
<p>They had tried before. A proper system, chosen with care, meant to pull the whole firm together. It got as far as go-live. And then, at go-live, the contract was repriced. The number that had been agreed was no longer the number. The firm looked at what it would now cost to run, year after year, and walked away. Years later, the memory of that was still the loudest thing in the room. Not &quot;we want software.&quot; Rather, &quot;we tried, it burned us, and we are not sure we want to try again.&quot;</p>
<p>If you are going to sell a firm like this anything, you have to understand that failure properly. And the honest version is not the flattering one.</p>
<h2>It did not fail because the software could not do the work</h2>
<p>It is tempting to tell the story as: the old system was wrong for architecture, it could not handle construction, so of course it failed. That is the version a competitor would love to sell. It is also not true.</p>
<p>The system they tried was Odoo, and Odoo is a capable platform. It has genuine construction and project capability, natively and through its add-ons. Plenty of firms run on it well. If you claim it simply cannot do the work, any principal who has actually looked at it will know you are selling rather than telling the truth, and you will lose them at that sentence.</p>
<p>The failure was not capability. It was two other things, and both are easy to repeat with any system if you are not careful.</p>
<h2>What actually failed</h2>
<p>The first was the shape of the deal. Odoo is priced per user. Every person you add to the system carries a fee. For a firm that wants everyone, the architect, the quantity surveyor, the site team, the finance office, working in one system, per-seat pricing turns &quot;get the whole firm on it&quot; into a bill that grows with the firm. When the contract was repriced at go-live, that structure was what made the new number frightening. The firm was not refusing software. It was refusing a cost that scaled against the very thing it wanted, which was everyone using it.</p>
<p>The second was subtler, and it is the one that matters most. The project tried to fit the firm into the software's idea of how a business works. Most business software carries a built-in picture: you sell products, you buy materials, you hold stock. An architecture firm does not live in that picture. It bills a fee agreed as a percentage of construction value. It has a quantity surveyor who prices and certifies. It issues interim payment certificates against a builder's payment applications. It runs a variation register. It keeps a drawing register where revisions matter as much as the drawings themselves. Ask a firm to squeeze those into fields built for selling goods and the system will technically run and quietly fail to describe the business. Staff will keep their real records in the spreadsheets they trust, and the expensive new system becomes a second place to type things.</p>
<h2>Fitting the software to the practice, not the reverse</h2>
<p>The lesson from a failure like this is not &quot;pick a different brand.&quot; It is a change of direction. The software should be shaped to the practice, not the practice to the software.</p>
<p>That means starting from the objects a firm actually runs on and making the system hold them: the project as the spine, with the agreed fee and the construction value on it; the three people who lead a project, the architect, the quantity surveyor, and the project manager, as real roles; the interim payment certificate, the variation register, and the drawing register as real records with the standing they carry in practice. On a flexible platform like ERPNext, the open-source business system, these can be built as first-class objects rather than forced into fields meant for something else. And the commercial shape matters as much as the technical one: a model where getting the whole firm onto the system does not punish you for every seat you add.</p>
<h2>The insight</h2>
<p>When a firm tells you their last system failed, listen past the brand. The failure that scarred them is almost never &quot;the software could not do it.&quot; It is usually a deal that punished them for growing, and a system that asked them to become a different kind of business than they are.</p>
<p>The firms that get burned twice are the ones who fix only the brand. The firms that get it right the second time fix the two things that actually broke: they choose a shape that lets everyone in without a rising toll, and they insist the software bend to the practice, because a practice that bends to its software slowly stops being itself.</p>
]]></content:encoded>
    </item>
  </channel>
</rss>
