⁨— Internal platforms⁩

⁨Internal platforms, built
around how you work.

⁨Portals, member directories, application reviews and the operations software your team lives in. Bilingual, mobile, no per-seat fee, and you own the code and the data.⁩

⁨The SPARK Innovation Hub: six weeks to launch, 500+ organisations, and a three-year partnership after it.⁩

If an off-the-shelf tool does 80% of it, we will tell you which one on the call.⁩

⁨Illustrative mockup of the SPARK Innovation Hub member directory, showing organisation cards with sector tags across the MENA network⁩
⁨The SPARK Innovation Hub member directory — illustrative mockup, not a live capture. Replace with a real capture once SPARK clears one.⁩
6⁨wks⁩⁨From start to a platform in real use, on the reference build⁩
100%⁨Of the code and the data are yours, on your infrastructure⁩
$0⁨Per seat. Adding the two-hundredth user costs what the first did⁩
3⁨yrs⁩⁨Code guaranteed after launch, defects and security⁩

⁨Six weeks is the SPARK Innovation Hub build, measured on that engagement rather than projected. Adoption figures — organisations onboarded, users migrated, concurrent load — sit with the client in section 9.⁩

⁨— What went wrong before⁩

⁨It started as a spreadsheet
and it never stopped being one.

⁨Three ways an organisation ends up running something important on software nobody chose.⁩

  1. ⁨The spreadsheet with a person attached⁩

    ⁨It works because one colleague knows which tab is current and which formula lies. The process is not documented anywhere except in their habits, and the risk is not the file — it is their notice period.⁩

  2. ⁨The platform bought for a different job⁩

    ⁨A CRM doing membership, a project tool doing applications, a form builder doing intake. Each is 60% right, none talks to the others, and every gap is closed by somebody copying between them.⁩

  3. ⁨The build that priced itself out⁩

    ⁨Quoted as an enterprise system, scoped for three years and cancelled in month eight. Nothing shipped, so nothing was learned — which is the expensive part.⁩

⁨The pattern is the same each time. The work is real and the software is borrowed.⁩

⁨— The trigger⁩

⁨Nobody can answer
a simple question quickly.

⁨Not "is the system slow". The call comes when a director asks how many applications are outstanding and the honest answer is that somebody will check.⁩

⁨Two people have different numbers⁩

⁨Both are reading real data from real files. Neither is wrong, because there is no single record that either could be wrong about.⁩

⁨Onboarding a new colleague takes a fortnight⁩

⁨Most of it is learning where things actually live and which of the four documents is authoritative. That cost repeats with every hire.⁩

⁨The reporting deadline drives the month⁩

⁨A funder or a board needs figures, and producing them is a week of assembly rather than an export. The work bends around the report instead of the report reflecting the work.⁩

⁨— What it is costing⁩

⁨Per seat, per month,
forever.

⁨The licence scales with the thing you want to grow⁩

⁨Per-user pricing means every colleague, partner or member you add raises the bill before they have done anything. Success is charged for.⁩

⁨Your process is bent to fit their model⁩

⁨The approval flow that matters is the one the tool does not support, so it happens in email beside the system that was supposed to record it.⁩

⁨The data is theirs until you export it⁩

⁨And the export is a CSV of the fields they chose to expose, without the relationships between them — which is the part that took years to accumulate.⁩

⁨— This market⁩

⁨Your users are on a phone,
and half of them read right to left.

⁨Internal software is where bilingual support is quietly dropped, because the assumption is that staff will cope. Across this region a platform used by members, partners or applicants is used by people who will not cope, and will simply stop using it.⁩

  • ⁨Arabic that turns the interface around⁩

    ⁨Navigation, tables, forms and every directional control mirror. A dashboard where the numbers still run left to right inside a right-to-left page is the tell that it was translated rather than built.⁩

  • ⁨Usable on the device people actually have⁩

    ⁨A partner filling in an application, a member updating a profile, a field officer logging a visit — none of them is at a desk. Internal does not mean desktop here.⁩

  • ⁨Sign-in by phone number, not corporate email⁩

    ⁨Members and partners often have no organisational address. A one-time code to a phone is the difference between an account they can access and one they abandon at the first password reset.⁩

  • ⁨Reporting shaped by whoever funds it⁩

    ⁨Programme platforms answer to donors and boards with their own formats and cycles. Reporting is a build requirement, and retrofitting it means re-recording data you already had.⁩

⁨Illustrative mockup of the SPARK Innovation Hub member directory in Arabic, mirrored right-to-left⁩
⁨The same directory screen in Arabic, mirrored — illustrative mockup, not a live capture⁩
⁨— The question everyone asks second⁩

⁨“Why build what we could buy?”

⁨Usually the right question, and often the right answer is that you should buy it. Here is how we decide, in writing.⁩

  • If an off-the-shelf tool does 80% of it, buy the tool. We will name it on the call. The 20% is rarely worth a build, and an agency that never says this is not assessing, it is selling.⁩
  • Build when the 20% is the reason you exist. If the part no tool supports is your actual process — how you approve, match, score or award — that is not a gap to work around.⁩
  • Build when per-seat pricing punishes growth. A platform whose whole purpose is to have more people on it should not cost more each time it succeeds.⁩
  • You own the code and the data. Your repository, your infrastructure, standard stack — Next.js and PostgreSQL. Any competent agency can take it on.⁩
⁨— The guarantee⁩

⁨We guarantee the code for three years.

⁨If something we built stops working the way it was specified, we fix it. No support contract required, no hourly rate, no argument about whose fault it is.⁩

⁨What it covers⁩
⁨Defects in the code we wrote, security patches to our own code, and keeping the build running against dependency updates.⁩
⁨What it does not⁩
⁨New features, changes to what was agreed, or third-party services failing on their side.⁩

⁨The guarantee lapses on code modified by a third party — the trade for owning it outright.⁩

⁨Buy the tool if it does eighty percent. Build when the twenty percent is the reason you exist.⁩
Said against our own interest. Most enquiries that reach this page should end in a recommendation to buy something. We would rather say it in the first half hour than in month eight.⁩
⁨— What we build⁩

⁨The parts that are always
the same, and the one that never is.⁩

⁨Every line below ran on the SPARK Innovation Hub. The scaffolding is common to every platform of this kind; the workflow in the middle is the part that is yours alone, and it is where the time goes.⁩

⁨Accounts, roles and what each one may see⁩⁨Members, staff, partners and administrators, with permissions that survive an audit.⁩
⁨Applications with a review and approval cycle⁩⁨Multi-step forms, document upload, a queue for reviewers and a decision that is recorded rather than emailed.⁩
⁨A directory people can actually search⁩⁨Across both languages, filtered by the attributes that matter to your sector rather than by name alone.⁩
⁨Reporting in the format your funder asks for⁩⁨Built to the reporting requirement rather than bolted on, so the export is a click and not a week.⁩
⁨Content and announcements your team edits⁩⁨Pages, opportunities and news changed by the people who own them, without a ticket.⁩
⁨Notifications that reach people where they are⁩⁨Email, SMS and WhatsApp, set per event rather than one switch for everything.⁩
⁨Migration from whatever you are on now⁩⁨Users, history and relationships moved across with the joins intact. On the reference build, 200 users and 55 content pieces with zero data loss.⁩
⁨Load tested before anyone depends on it⁩⁨250+ concurrent users on the reference build, proven before launch rather than discovered after.⁩
⁨— The differentiator⁩

⁨Six weeks, because we
build the middle first.

⁨Platforms of this kind are eighty percent scaffolding — accounts, roles, forms, search, notifications. That part is known work. The remaining fifth is your process, and it is the only part nobody can estimate from a brief. So it goes first, while there is still budget to be wrong.⁩

  1. ⁨Week one — the workflow on a wall⁩

    ⁨The approval, matching or scoring process drawn out end to end, including the exceptions people handle by hand today. Most of the disagreement surfaces here, which is where it is cheapest.⁩

  2. ⁨Weeks two and three — that workflow, running⁩

    ⁨Only the part that is yours alone, working against real data, with no styling worth mentioning. You use it before we build anything around it.⁩

  3. ⁨Weeks four and five — the scaffolding⁩

    ⁨Accounts, roles, directory, search, notifications and reporting. Known work, done fast, because the risky part is already proven.⁩

  4. ⁨Week six — migration and load⁩

    ⁨Existing users and history moved with relationships intact, then load tested past the number you expect. Live at the end of it.⁩

⁨The scaffolding is known work. Your process is the only part nobody can estimate, so it is the part we build first.⁩
Why the order matters more than the speed. Six weeks is not a result of working faster. It is a result of finding out in week two whether the thing was understood, rather than in month five.⁩
⁨— The platform we built⁩

⁨SPARK Innovation Hub —
“Facebook for changemakers.”

⁨Built for SPARK, the Dutch development organisation, as the platform where more than five hundred organisations across the Middle East and Africa find each other, publish opportunities and apply to them. Live in six weeks, and a partnership that has run three years since.⁩

500+⁨Organisations onboarded onto the platform⁩
200⁨Users migrated from the old system with zero data loss⁩
250+⁨Concurrent users load-tested before launch⁩
3⁨Years of partnership since it went live⁩

⁨From Umbrella500_Canonical_Numbers.md — SPARK Innovation Hub Platform. The canonical file describes these as commercial-grade delivery proof even though the client was an NGO, which is exactly why they sit on a companies page.⁩

⁨The platform is at hub.spark.ngo , and is the one visual proof on this page you can check yourself today. Read the case study

⁨SPARK is an organisation and this is a companies page. The build was a product delivery to commercial standards, which is how the canonical numbers file describes it, and we would rather say that than let a reader assume otherwise.⁩

⁨— Who builds it⁩

⁨Two founders.
Not a sales team and a queue.

⁨The people you meet on the call are the people who do the work.⁩

⁨Noora Shanak, Co-founder and COO of Umbrella500⁩

⁨Noora Shanak⁩

⁨Co-founder & COO · Project lead⁩

⁨Twenty years as a consultant and technology expert. Co-founder and COO of ShopGo, where she helped more than 1,000 MENA businesses scale online. She leads the technology practice and ran the Innovation Hub delivery.⁩

  • ⁨1,000+ businesses scaled⁩
  • ⁨20+ years in technology⁩
  • ⁨Innovation Hub lead⁩
⁨Saleem Najjar, Co-founder and CEO of Umbrella500⁩

⁨Saleem Najjar⁩

⁨Co-founder & CEO⁩

⁨Co-founder of ShopGo.me, acquired. He has supported over 13,000 entrepreneurs across the region and leads client relationships, including the three-year SPARK partnership that followed this build.⁩

  • ⁨13,000+ entrepreneurs supported⁩
  • ⁨ShopGo · acquired exit⁩
  • ⁨3-year SPARK partnership⁩
⁨— The alternatives⁩

⁨Four ways to get this.
Three of them are not us.

⁨Most enquiries that reach this page should end in one of the first three columns, and we will say which on the call.⁩

⁨An off-the-shelf tool⁩

⁨Right far more often than agencies admit.⁩

⁨Membership platforms, grant management systems and CRM suites solve most of this, immediately, with support attached. The cost is per seat and the process bends to fit theirs.⁩

Choose it if: it covers eighty percent and the missing fifth is not the reason you exist.⁩

⁨A no-code build⁩

⁨Fast, cheap, and fine until it is load-bearing.⁩

⁨Airtable, Notion or a form builder wired together. Genuinely good for proving the workflow. The ceiling arrives at permissions, at reporting, and at the point where it holds data you cannot afford to lose.⁩

Choose it if: you are still deciding what the process should be.⁩

⁨An in-house team⁩

⁨The right end state, at the wrong start.⁩

⁨A permanent team is better than any agency once the platform is the product. Hiring for it before there is a working system means paying salaries through the discovery phase, which is the least productive way to buy it.⁩

Choose it if: the platform is your business and you have already proven it.⁩

⁨A custom build⁩

⁨Costs more on day one. Costs nothing per seat, ever.⁩

⁨You own the code, the data and the process. No per-user fee, so growth stops raising the bill. The reference build reached real use in six weeks, and the workflow that made it worth building was running in week three.⁩

Choose it if: the fifth no tool supports is the reason the organisation exists.⁩

⁨If an existing tool does eighty percent of what you need, we will name it on the call and tell you not to build. That happens more often than not.⁩

⁨— Questions⁩

⁨The ones that decide it.⁩

⁨How do we know we should build rather than buy?

⁨Write down the one process that is genuinely yours — how you approve, match, score or award. If an existing tool supports it, buy the tool. If every tool makes you work around it, that is the case for building, and it is the only case we accept.⁩

⁨Was six weeks a real timeline?

⁨Yes, on the SPARK Innovation Hub, from start to real use with 200 migrated users. It is in Umbrella500_Canonical_Numbers.md against that engagement. Your timeline depends on how much of your process is genuinely unusual, and we will give you a range against it rather than repeat this number.⁩

⁨Who owns the data?

⁨You do, on your infrastructure, in a standard PostgreSQL database. Not a hosted account we administer. If you leave, you keep the running system rather than an export of it.⁩

⁨What about AI in the platform?

⁨Where it does a job you can name — matching applicants to opportunities, summarising a queue, answering from your own documents. We have built an assistant that operates a workflow rather than describing it, on a partner engagement. We will not put a chat box on a platform because it is expected.⁩

⁨Can our team change it after launch?

⁨Content, users, permissions and the reporting views, yes, without a developer. Changing the workflow itself is code, and you have the repository, the documentation and a standard stack so your own developer or another agency can do it.⁩

⁨Do you maintain it afterwards?

⁨We can, on a flat retainer, or your team can. The three-year code guarantee applies either way — defects, security patches and dependency updates on what we built are covered whether or not you retain us.⁩

⁨— The brief⁩

⁨The system your team
actually works in.

⁨Tell us the one process that is genuinely yours and what you are running it on today. Thirty minutes, no cost, and we will name the tool to buy if there is one.⁩

⁨Or write directly: [email protected]

⁨Opens your mail app with the details filled in. Nothing is stored on this page.⁩