DEV Community: John Moore

How a Custom Dashboard Can Replace 5 SaaS Subscriptions

John Moore — Wed, 08 Apr 2026 10:46:26 +0000

You open Chrome in the morning and there are eight tabs. Xero for accounting. Shopify for orders. HubSpot for leads. Trello for tasks. Google Sheets for the stuff that doesn't fit anywhere else. Maybe a couple more.

Each tool does its job. But none of them talk to each other properly. You're the glue — copying data, cross-referencing tabs, building mental models of how everything connects.

What if one screen showed you everything that matters?

The SaaS Sprawl Problem

Most businesses don't set out to use 5+ SaaS tools. It happens gradually:

You need to track orders — sign up for Tool A
You need a CRM — sign up for Tool B
Tool A doesn't report the way you need — add a spreadsheet
You need to connect A and B — sign up for Zapier
Zapier breaks — add another spreadsheet as a backup

Before you know it, you're paying hundreds a month for tools that each solve 20% of your problem, with spreadsheets filling the gaps.

What a Custom Dashboard Looks Like

A custom dashboard pulls data from your existing sources into a single view. It doesn't replace Xero or Shopify — those are good at what they do. It sits on top, showing you the metrics and status updates that matter to your business.

A typical dashboard for a small e-commerce business might show:

Today's revenue (from Shopify) alongside outstanding invoices (from Xero)
Open support tickets ranked by urgency
Inventory alerts — items running low or overstocked
Marketing performance — which campaigns are driving orders this week
Team tasks — what's due today, what's overdue

All on one screen. No tab-switching. No mental arithmetic.

The Tools You Can Often Eliminate

When you have a dashboard that shows the right data, you typically stop needing:

Reporting add-ons — no more paying for analytics tools when your dashboard has the charts you need
Integration platforms (Zapier/Make) — your dashboard connects directly to your data sources
Project management tools — if your workflow is simple, the dashboard can track tasks
Notification services — the dashboard alerts you to what matters
Spreadsheet workarounds — the dashboard replaces the "glue" spreadsheets

Not every business will drop all five. But most can eliminate at least two or three.

When a Dashboard Makes Sense

A custom dashboard is worth building when:

You check 3+ tools every morning just to understand what's happening
You maintain spreadsheets that pull data from other systems
Your team asks you for numbers that require checking multiple sources
You've been wanting "one place" to see everything but no SaaS tool quite does it

When It Doesn't Make Sense

Don't build a dashboard when:

One tool does 90% of what you need — just use that tool's built-in reports
Your data sources change constantly — a dashboard will be constantly out of date
You don't know what metrics matter — figure that out first, then build

The Build

A focused dashboard for a small business typically takes 2-4 weeks to build. It connects to your existing APIs (Shopify, Xero, Stripe, etc.), pulls the data you care about, and presents it clearly.

The investment pays for itself through:

Eliminated SaaS subscriptions
Time saved switching between tools
Better decisions from seeing everything in context
Less stress from not having to piece together the full picture manually

Client Portals: How They Save Your Team 10+ Hours a Week

John Moore — Wed, 08 Apr 2026 10:45:09 +0000

If your team spends a chunk of every day answering the same client questions — "What's the status of my order?" "Can you send me that document?" "When will it be ready?" — you have a portal problem, not a staffing problem.

A client portal is a secure, branded space where your customers can log in and help themselves. Check order status. Download invoices. Submit requests. View project updates. All without picking up the phone or sending an email.

The Problem With Email-Based Client Communication

Email feels free, but it's one of the most expensive communication channels you have. Every "quick question" from a client takes:

Time to read and understand the request
Time to look up the answer in your system
Time to compose a reply
Time to deal with the follow-up when the client doesn't understand your answer

Multiply that by 20 clients and you've got someone on your team spending half their day as a human API between your systems and your customers.

What a Client Portal Actually Does

A good client portal eliminates the middleman. Instead of your team fetching information and passing it along, clients get it directly. Common features include:

Order/project status tracking — clients see exactly where things stand without asking
Document sharing — invoices, reports, certificates, quotes — all in one place
Request submission — structured forms instead of messy email threads
Messaging — threaded conversations attached to specific orders or projects
Appointment booking — clients pick available slots without back-and-forth

The key insight: a portal doesn't just save your team time. It makes your clients happier. They get instant answers instead of waiting for someone to reply.

The 10-Hour Calculation

Here's how the hours add up for a typical service business with 30-50 active clients:

Task	Without Portal	With Portal
Status update requests	5 hrs/week	0 hrs
Document requests	2 hrs/week	0 hrs
Scheduling back-and-forth	2 hrs/week	0 hrs
Data entry from email requests	3 hrs/week	1 hr
Total	12 hrs/week	1 hr/week

That's 11 hours back. At even a modest hourly rate, the portal pays for itself in the first month.

Build vs Buy

For basic needs, tools like Copilot, SuiteDash, or Clinked might work. But they come with limitations:

Your branding takes a back seat to theirs
You can't customise the workflow to match how you actually operate
Integration with your existing systems requires workarounds
You pay per user, which gets expensive as you grow

A custom-built portal costs more upfront but fits your business exactly. It connects to your existing database, follows your workflow, and looks like your brand.

Who Needs a Client Portal?

Any business where clients regularly need information that lives in your systems:

Professional services (accountants, solicitors, consultants) — document sharing, project updates
Jewellers and craftspeople — repair status, commission tracking, valuation certificates
Agencies — project dashboards, approval workflows, reporting
Tradespeople — job tracking, quotes, scheduling
Property management — maintenance requests, documents, payments

Getting Started

You don't need to build everything at once. Start with the single biggest time-waster:

Identify your most common client request — the thing you answer 10 times a week
Build a portal that answers just that one question — status tracking, document access, whatever it is
Measure the time saved — you'll have your business case for expanding it

Outgrown Airtable? Here's What to Do Next

John Moore — Fri, 03 Apr 2026 09:17:03 +0000

Airtable is a genuinely great tool. It sits in that sweet spot between a spreadsheet and a database, and for thousands of small businesses it's the first step towards organising their operations properly. If you're reading this, it probably served you well for a long time.

But you're here because something has changed. The tool that once made everything easier is now creating friction. You're not imagining it — and you're not alone. Here's how to know for sure, and what to do about it.

Signs You've Outgrown Airtable

Outgrowing Airtable doesn't happen overnight. It creeps up on you. Here are the warning signs:

You're hitting record limits. Airtable's free plan caps you at 1,000 records per base. Even on paid plans, the 50,000 records-per-table limit is a hard ceiling. If you're archiving old records just to stay under the limit, or splitting data across multiple bases to work around it, your database has outgrown the container.

Per-seat costs are escalating. Airtable's pricing model charges per user. That's fine when it's just you and a co-founder. But as your team grows — an operations manager, a sales rep, a part-time bookkeeper who only logs in twice a month — the monthly bill climbs fast. Suddenly you're paying for seats that barely get used.

Your automations are getting fragile. Airtable's built-in automations are useful for simple triggers, but complex multi-step workflows quickly become brittle. When an automation fails silently at step four of seven, and nobody notices until a client chases you, that's a reliability problem disguised as a feature.

You have a growing stack of Zapier and Make workarounds. When Airtable can't do something natively, the standard advice is to connect it to Zapier or Make. One or two integrations are fine. But when you have a dozen zaps holding your operations together, you've built a distributed system that nobody can see the full picture of.

Your clients or external users can't use it. Airtable Interfaces have improved, but they're still limited. If you need clients, customers, or suppliers to interact with your data — submitting forms, viewing their own records, getting notifications — Airtable wasn't designed for that.

Your Three Options

Once you've recognised the problem, you have three realistic paths forward.

Option 1: Upgrade to Airtable Business

Airtable's Business plan costs $45 per seat per month. It raises the record limit to 125,000 per table and adds features like Gantt views and advanced automations. If your main issue is the record cap and you have a small team, this might buy you time.

But it doesn't solve the fundamental architectural limits. You're still on a no-code platform with no-code constraints. And at $45/seat, a team of 10 is paying $5,400 per year — with no guarantee you won't hit the next ceiling.

Option 2: Switch to Another No-Code Platform

Notion, Baserow, NocoDB, SmartSuite — there's no shortage of alternatives. Some are cheaper. Some are open-source. Some have higher record limits.

But switching from one no-code platform to another is like moving from a one-bedroom flat to a slightly larger one-bedroom flat. You solve the immediate space problem, but you hit the same walls again in a year or two.

Option 3: Build Custom Software

This is the option most people dismiss too quickly, because "custom software" sounds expensive, slow, and enterprise-scale. But it doesn't have to be any of those things.

A custom web app, purpose-built for your workflow, is a one-time development cost. You own it outright. There are no per-seat fees. It scales as your team and data grow, without artificial limits.

The Real Cost Comparison

Let's put numbers on it. Take a team of 10 people using Airtable over three years:

Airtable Business: 10 seats × $45/month = $450/month. Over 3 years, that's $16,200. Add in Zapier plans ($50–$100/month), and you're looking at closer to $20,000 over three years for a system you can't fully control.

Custom development: A focused web application typically costs between $5,000 and $15,000. Hosting runs $20–$50/month. Over three years: $5,700–$16,800 total. And at the end, you own it. No per-seat costs. No record limits.

The crossover point comes faster than most people expect — often within the first year.

The Migration Isn't as Scary as You Think

Airtable makes it straightforward to export your data as CSV files. Every table, every view, every record — it all comes out cleanly. A good developer builds the import process alongside the application.

You don't even have to move everything at once. Most businesses start by migrating their core workflow — the thing that's causing the most pain — and keep Airtable running for everything else while they transition.

What "Graduation" From Airtable Looks Like

The smartest approach isn't to abandon Airtable entirely. It's to graduate from it strategically.

Keep Airtable for the simple stuff — internal task lists, content calendars, lightweight project tracking. It's excellent at those things.

Build custom software for your core workflow — the system your business depends on, the one that touches customers, handles money, or manages your critical operations. That's where the record limits, per-seat costs, and automation fragility actually hurt you.

The result is the best of both worlds: the flexibility of Airtable where it works, and purpose-built software where it matters.

Hiring a Developer for the First Time: A No-Jargon Guide for Business Owners

John Moore — Sun, 29 Mar 2026 20:33:55 +0000

If you are a business owner thinking about hiring a developer for the first time, there is a good chance you feel a bit out of your depth. Maybe you have no idea what questions to ask. Maybe you are worried about getting ripped off or ending up with something that does not work. Maybe you are not even sure whether you actually need a developer at all.

Take a breath. You are not alone. The vast majority of small business owners have never hired a developer before, and almost all of them felt exactly the way you do right now. The good news is that the process does not have to be mysterious or stressful. This guide will walk you through everything you need to know — in plain English, with no jargon.

It Is Completely Normal to Feel Out of Your Depth

Let us get this out of the way first. You run a business. You are an expert at what you do — whether that is making jewellery, running a shop, managing a team, or serving customers. Software development is a completely different world, and there is no reason you should already know how it works.

Most business owners we talk to start the conversation with some version of "I'm sorry, I don't really know how any of this works." That is absolutely fine. A good developer expects this and will meet you where you are. You would not expect a developer to walk into your workshop and know how to set a diamond. The same thing applies in reverse.

The fact that you are reading this guide means you are already doing the right thing — getting informed before making a decision.

Types of Developers: Who Does What?

Not all developers are the same. Here are the main types you will come across, and when each one makes sense.

Solo developer (independent). One person who handles everything from understanding your needs to building and deploying the software. Best for small to medium projects where you want a direct relationship with the person doing the work. Communication is usually simpler because there is no chain of people between you and the builder.
Freelancer (via a platform). Similar to a solo developer, but typically found through platforms like Upwork or Fiverr. Quality varies enormously. Some are excellent, some are not. It can be harder to vet them, and you may have less recourse if things go wrong. Best for small, well-defined tasks where you know exactly what you need.
Small agency (2–10 people). A small team that can handle larger projects and usually has designers as well as developers. Good for projects that need multiple skill sets. Costs more than a solo developer, but you get a broader team. Communication may go through a project manager rather than the developer directly.
Offshore team. A development team based in a country with lower labour costs, often India, Eastern Europe, or South East Asia. Can be significantly cheaper on paper, but comes with challenges: time zone differences, language barriers, and cultural differences in how work is managed. Best for businesses that have some technical knowledge in-house to manage the relationship. Not usually recommended for a first-time buyer who needs close collaboration.

For most small businesses hiring a developer for the first time, a solo developer or a small agency in your own country is the safest starting point. The direct communication and shared context make everything easier.

What to Look For in a Developer

You do not need to evaluate someone's code to know whether they are a good fit. Here is what actually matters.

A portfolio of shipped work. Not a list of technologies they know, but actual things they have built that are live and working. Can they show you real products that real people use? If they have built things for businesses similar to yours, even better.
Clear communication. When you talk to them, do you understand what they are saying? Do they explain things in a way that makes sense to you? A developer who cannot communicate clearly with a non-technical person will struggle to build something that fits your needs.
Fixed pricing (or at least a clear estimate). A developer who gives you a fixed price for a defined scope is taking on the risk of their own estimate being wrong. That is usually a sign they have done this before and know what they are doing. Hourly billing is not inherently bad, but for a first-time buyer it can feel risky because you have no idea how many hours something "should" take.
Willingness to explain things in plain English. You should never feel stupid in a conversation with your developer. If they make you feel that way, that is a them problem. A good developer will patiently explain concepts without talking down to you.
A clear process. They should be able to tell you exactly what happens after you say yes — what the steps are, what you will need to provide, how long each stage takes, and when you will get to see progress.

Red Flags: When to Walk Away

Here are warning signs that should make you think twice before hiring someone.

No portfolio. If they cannot show you anything they have built, you have no way to judge the quality of their work. Everyone has to start somewhere, but you probably do not want your business-critical project to be someone's first.
They will not give a fixed quote. If they refuse to commit to any kind of price and insist on billing hourly with no cap or estimate, you could end up with a bill that is far higher than expected. A developer who has done similar work before should be able to give you at least a ballpark figure.
Heavy use of jargon. If every conversation leaves you more confused than when it started, that is a problem. Some developers hide behind jargon — either because they cannot communicate clearly or because they want you to feel dependent on them. Neither is good.
No process explanation. If they cannot describe how the project will work — what happens first, what happens next, when you will see something — they are probably making it up as they go along.
They want to start coding immediately. A developer who jumps straight into building without first understanding your business, your problem, and your goals is almost guaranteed to build the wrong thing. Discovery and planning should always come before a single line of code is written.
They never push back. If a developer agrees with absolutely everything you say and never asks "are you sure you need that?" or "have you considered this alternative?", they are not thinking critically about your problem. You want someone who will challenge your assumptions — respectfully — because that is how you end up with a better result.

What the Process Typically Looks Like

Every developer works slightly differently, but a professional engagement usually follows something like this.

Discovery call. A conversation (usually 30–60 minutes) where the developer asks about your business, your problems, and what you are hoping to achieve. This is not a sales pitch — it is a fact-finding exercise. You should do most of the talking.
Scoping. The developer goes away and works out what needs to be built, how long it will take, and how much it will cost. They may come back with questions. This stage might take a few days.
Quote and proposal. You receive a written proposal that describes what will be built, what it will cost, and how long it will take. This is where you decide whether to go ahead. There should be no pressure.
Build. The developer starts building. A good developer will show you progress regularly — not just at the end. You should expect to see something working within a few weeks at most, even if it is not finished.
Review and feedback. You test what has been built and provide feedback. Things get adjusted. This back-and-forth is normal and healthy — it is not a sign that something has gone wrong.
Deploy. The finished software goes live. The developer handles the technical side of making it available to you and your users.
Support. After launch, bugs may surface and small adjustments may be needed. A good developer will include a support period after launch. Make sure you understand what is included and what costs extra.

What Does It Cost?

This is the question everyone wants answered, and the honest answer is "it depends." But here are some realistic ranges for Ireland and the UK as of 2026.

Solo developer hourly rate: EUR 50–80 per hour. This is typical for an experienced independent developer in Ireland or the UK.
Agency hourly rate: EUR 100+ per hour. Agencies have higher overheads (offices, project managers, designers), which is reflected in the price.
Fixed-price projects for SMBs: EUR 3,000–25,000 for most small business projects. A simple internal tool or basic web application might be at the lower end. A more complex system with multiple user types, integrations, and custom workflows will be at the higher end.

Be cautious of quotes that seem dramatically lower than these ranges. If someone quotes EUR 500 for something that three other developers have quoted EUR 8,000 for, there is a reason. Either they have misunderstood what you need, or the quality of the result will reflect the price.

Also be aware that the cheapest option upfront is not always the cheapest in the long run. Poorly built software costs more to fix, maintain, and eventually replace than software that was built properly the first time.

How to Brief a Developer

Once you have found someone you want to talk to, the next step is explaining what you need. This can feel daunting, but it does not have to be. You do not need technical knowledge — you just need to describe your problem clearly.

The short version is: start with the problem (not the solution), describe your current workflow, explain who will use it, share examples of things you like and dislike, and be upfront about your budget and timeline.

Questions to Ask Before You Hire

Here are some good questions to ask any developer before you commit. You do not need to ask all of them, but pick the ones that matter most to you.

Can you show me something similar you have built before?
What does your process look like from start to finish?
Will you provide a fixed price, or do you bill hourly?
How often will I see progress during the build?
What happens if I need changes after the project is finished?
Do you offer ongoing support, and what does it cost?
Who owns the code when the project is complete?
What happens if the project takes longer than expected — who absorbs the extra cost?
Can you explain in plain terms how the software will work?
What do you need from me during the project?

Pay attention to how they answer as much as what they answer. Are they patient? Do they explain things clearly? Do they seem genuinely interested in your business, or are they just trying to close the sale?

Funding: The LEO Grow Digital Voucher

If you are a small business in Ireland, there is a funding option worth knowing about. The Local Enterprise Office (LEO) offers a Grow Digital Voucher that can cover 50% of eligible digital project costs, up to EUR 5,000. That means if your project costs EUR 10,000, the LEO could fund EUR 5,000 of it.

Eligibility requirements include having 1–50 employees, trading for at least 6 months, and completing a Digital for Business programme beforehand. You apply through your local LEO office. It is worth checking your eligibility before you start — having half the cost covered makes a significant difference for a small business.

Your developer should be able to help you with the application if needed, or at least provide the kind of quote and project description the LEO requires.

You Might Not Even Need a Developer

Here is something that an honest developer will tell you: not every problem requires custom software. Sometimes the answer is a better use of tools you already have. Sometimes it is a no-code platform like Airtable or Notion. Sometimes it is a Shopify app that already exists.

A good developer will tell you this upfront, even if it means losing the work. If someone is trying to sell you a custom build when a EUR 20-a-month subscription would solve the same problem, that is a red flag.

Ready to Have the Conversation?

If you have been putting this off because it all felt too complicated or too risky, we hope this guide has made it feel a bit more manageable. Hiring a developer does not have to be a leap of faith. With a little preparation and the right questions, you can find someone who genuinely understands your business and builds something that makes your life easier.

Originally published at jmsdevlab.com

No-Code vs Custom Software: When Free Tools Stop Being Free

John Moore — Sun, 29 Mar 2026 15:06:39 +0000

No-code platforms are genuinely impressive. Airtable, Bubble, Glide, Retool — they let non-technical people build real applications without writing a line of code. For prototyping, for solo founders, for simple internal tools, they can be exactly the right choice.

But there's a pattern I see over and over: a business adopts a no-code platform, builds something useful, the team grows, the requirements get more complex — and suddenly the "affordable" tool costs more than custom software ever would have.

The Per-Seat Trap

Per-seat pricing is the reason no-code costs catch people off guard. Here's what the main platforms actually charge in 2026:

Airtable — $20–$45 per seat/month on Team and Business plans
Bubble — $29/mo Starter, up to $349/mo for Team
Glide — $199/mo for Business (the first tier most growing teams need)
Retool — $10–$50 per builder/month, plus viewer seats

At 20 users, Airtable Business costs nearly $11,000 annually. Custom software costs the same whether you have 5 users or 500.

Team Size	Airtable Business/year	Custom Software/year
5 users	$2,700	~$600 (hosting only)
10 users	$5,400	~$600
20 users	$10,800	~$600
50 users	$27,000	~$600

The Hidden Costs Nobody Mentions

Consultant Fees

No-code is marketed as "anyone can use it." In practice, most businesses hire no-code consultants at $40–$200/hour. That's close to what a custom developer charges — except the consultant's work is locked inside a platform you don't own.

Platform Lock-In

Everything you build on Airtable belongs to Airtable. Your automations, views, integrations — none of it is portable. If they raise prices, change their API, or shut down, you start over.

The Rewrite Problem

Many no-code projects get rebuilt in custom code within 2 years. Performance limits, security requirements, or simply outgrowing the platform. That means paying twice — once for no-code, and again for custom.

3-Year Cost Comparison

Spreadsheet Replacement (10 users)

Approach	Year 1	Year 2	Year 3	Total
Airtable	$5,400	$5,400	$5,400	$16,200
Custom	$4,000	$600	$600	$5,200

Niche CRM (25 users)

Approach	Year 1	Year 2	Year 3	Total
Airtable + consultant	$17,500	$14,500	$14,500	$46,500
Custom	$10,000	$1,200	$1,200	$12,400

The Crossover Point

Under 5 users — No-code is often cheaper
5–10 users — Depends on complexity
10–20 users — Custom frequently wins on total cost
20+ users — Custom almost always wins

When No-Code IS Right

Prototyping — Testing an idea before committing budget
Solo founders — Per-seat pricing isn't a problem yet
Simple, stable requirements — Forms, tables, basic automations
Temporary tools — Specific project or trial period

The Graduation Path

Spreadsheets — Start here. Free, flexible, everyone knows them.
No-code — When spreadsheets break, validate your process here.
Custom software — When costs climb and limitations bite, graduate to a custom build. By now you know exactly what you need.

The mistake isn't starting with no-code. The mistake is staying past the point where it stops making financial sense.

GDPR Note for European Businesses

Airtable, Bubble, Glide, and Retool are all US-based. Your data is subject to the US CLOUD Act. Custom software can be hosted on EU infrastructure with full data sovereignty.

Originally published at jmsdevlab.com

I Replaced a Client's 47-Tab Spreadsheet with a Custom App. Here's What I Learned.

John Moore — Sun, 29 Mar 2026 09:15:56 +0000

Last year I built a custom app for a jewellery retailer who was running their entire business from a Google Sheets workbook. 47 tabs. Vlookups nested inside vlookups. A tab called "DO NOT DELETE" that nobody understood but everyone was afraid to touch.

Here's what happened, what I learned, and what I'd tell any developer considering this kind of project.

The Spreadsheet Was Load-Bearing

The owner had been adding tabs for six years. What started as an inventory list had grown into:

Customer records (with purchase history across 3 tabs)
Repair job tracking (with a colour-coding system only she understood)
Commission calculations for 4 staff members
Valuation certificates (linked to a separate folder of PDFs)
Monthly reporting (copy-paste from other tabs into a "Reports" tab)

It worked. Barely. But it worked. And that's the dangerous part — it worked just well enough that nobody had the urgency to replace it, but poorly enough that everyone lost hours every week to errors, slowness, and "who changed this cell?"

Why They Finally Called Me

Two things broke at once:

A new employee accidentally deleted a formula that cascaded through the commission tab. Nobody noticed for three weeks. Three weeks of wrong pay calculations.
Google Sheets started timing out because the workbook was too large. They couldn't open the repair tracker during busy periods — exactly when they needed it most.

The breaking point wasn't a feature request. It was a failure.

What I Actually Built

Not a replica of the spreadsheet. That's the mistake most developers would make — faithfully reproducing every tab and formula in a web app. That just gives you a slower, more expensive spreadsheet.

Instead, I sat with the owner for two days and asked one question repeatedly: "What decision does this data help you make?"

Turns out, about 60% of the spreadsheet was legacy. Data captured because it seemed important at the time but never actually used. We stripped it out.

The app I built had:

A customer CRM with purchase history and communication notes (replacing 3 tabs)
A repair tracker with status workflow, photos, and automated customer notifications (replacing the colour-coded tab)
A commission engine that calculated automatically and couldn't be accidentally broken (replacing the formula nightmare)
Valuation management with PDF generation and digital delivery (replacing the folder of files)

Built with TypeScript, React, Node.js, PostgreSQL, and Prisma. Deployed on Railway. Total build time: 5 weeks.

What I Learned

1. The real requirements aren't in the spreadsheet

They're in the workarounds. The colour-coding system. The sticky notes on the monitor. The "always do X before Y" verbal instructions passed between staff. Interview the people, not the cells.

2. Business owners don't want features — they want fewer mistakes

The owner didn't ask for a dashboard or charts or a mobile app. She asked for "something that won't let someone accidentally delete three weeks of pay data." Start with the pain, not the polish.

3. Data migration is the hardest part

Six years of inconsistent data entry. Names spelled differently. Dates in three formats. Empty fields where there should be values. I spent more time cleaning and migrating data than building the app.

4. Don't build what they have — build what they need

If I'd replicated every tab, I'd have built a 12-screen app. Instead I built 4 screens that covered 95% of daily operations. Less code, fewer bugs, faster delivery, easier to learn.

5. Training is product work

The best feature in the app is the onboarding tour. Three minutes, covers everything. If a new staff member can't use it without training, the UX needs work — not a manual.

The Numbers

Build cost: Mid four figures (fixed price, no hourly billing)
Monthly hosting: Under EUR 20
Time saved: Estimated 8-10 hours per week across the team
Data errors: Zero accidental deletions since launch
ROI payback: Under 4 months

Should You Build Custom Software for Spreadsheet Replacement?

Only if these are true:

Multiple people use the spreadsheet daily
You've had at least one serious data error
The workarounds are becoming the process
The spreadsheet is slowing down or timing out
You can articulate the 3-5 decisions the data actually supports

If all five are true, a custom app probably pays for itself in months.

If only 1-2 are true, you probably need a better spreadsheet, not custom software.

I'm John, a developer in Cork, Ireland. I build custom software and Shopify apps for businesses that are too specific for off-the-shelf tools. If your spreadsheet is holding your business together with vlookups and prayers, I'd like to hear about it.

Buy vs Build: When Should a Small Business Build Custom Software?

John Moore — Sat, 28 Mar 2026 23:44:14 +0000

You need software to run part of your business. Maybe you've already tried a few tools and nothing quite fits. Maybe you're drowning in spreadsheets. Maybe a well-meaning friend said "just get a developer to build it."

The answer isn't always custom software. Sometimes it is. And sometimes the right answer is somewhere in between. Here's a practical framework for deciding.

The Three Options

Every business software decision falls into one of three buckets:

Buy (off-the-shelf SaaS) — Subscribe to an existing product. Xero for accounting, HubSpot for CRM, Monday.com for project management.
Build-lite (no-code/low-code) — Use platforms like Airtable, Notion, Zapier, or Glide to assemble something yourself without writing code.
Build (custom development) — Hire a developer to create software tailored exactly to your business.

None of these is inherently better than the others. The right choice depends on your problem, your budget, and where you are as a business.

When to BUY: Off-the-Shelf SaaS

If your problem is common, the solution probably already exists — and it's probably good.

Buy when:

The problem is well-understood and generic (accounting, email marketing, basic CRM)
Your workflow matches what the tool was designed for
You have fewer than 10 users and per-seat pricing is manageable
You need something today, not in six weeks

Honestly, if a well-known SaaS tool does 80% of what you need and the other 20% isn't critical, just use the SaaS tool.

When to BUILD-LITE: No-Code and Low-Code

No-code sits in a useful middle ground. More flexible than SaaS, less commitment than custom.

Build-lite when:

You're prototyping a process and aren't sure what you need yet
Your team is small (fewer than 5 people)
The workflow is relatively simple — forms, tables, basic automations
You want to test an idea before committing real budget

The limitations: No-code tools hit a ceiling. Complex business logic gets messy. Performance slows as data grows. And per-seat costs climb quickly once you have more than a handful of users.

When to BUILD: Custom Development

Custom software makes sense when your needs are specific enough that nothing off the shelf fits well, and significant enough that the investment pays for itself.

Build when:

Your workflow is niche. You've looked at the SaaS options and none handle the way your business actually operates.
Per-seat costs are killing you. Once you hit 10+ users, SaaS subscriptions compound fast.
Data sensitivity matters. Full control for GDPR, data residency, or industry compliance.
The tool IS your competitive advantage. Why use the same software your competitors use?
You've outgrown everything else. Five subscriptions, three spreadsheets, and a shared email inbox is not a system.

A Simple Decision Framework

Is this a common business problem? → Buy SaaS.
Is my process still evolving? → Start with no-code.
Can an existing tool handle 80%+ of what I need? → Buy it.
Do I have fewer than 5 users and simple workflows? → No-code is probably fine.
Is per-seat pricing becoming painful? (10+ users) → Custom starts making financial sense.
Is this process core to my competitive advantage? → Build custom.
Have I outgrown SaaS and no-code? → Build custom.

The Hybrid Approach

The smartest businesses don't go all-in on one approach. They buy for the common stuff and build for the parts that make them different.

Use Xero for accounting. Use Mailchimp for newsletters. Use Shopify for your storefront. But that client portal your customers keep asking for? The commission tracker that doesn't exist for your industry? Build those.

What This Actually Costs: A 3-Year Comparison

For a small business with 10 users needing a workflow management solution:

	Year 1	Year 2	Year 3	3-Year Total
SaaS	£6,000-12,000	£6,000-12,000	£6,000-12,000	£18,000-36,000
No-Code	£4,000-8,000	£2,400-6,000	£2,400-6,000	£9,000-20,000
Custom	£4,000-17,000	£750-2,100	£750-2,100	£5,500-21,000

SaaS has the lowest entry cost but the highest long-term cost. Custom has the highest upfront cost but flattens out.

Funding: The LEO Grow Digital Voucher

Irish small businesses may access the Local Enterprise Office Grow Digital Voucher, covering 50% of eligible project costs up to EUR 5,000. A EUR 10,000 project could reduce to EUR 5,000 out-of-pocket.

What to Do Next

Don't start by looking at software. Start by writing down the process. What actually happens, step by step, when you do the thing that needs to be better? That's the brief. That's what tells you whether to buy, build-lite, or build.

JMS Dev Lab — Custom software for businesses that are too unique for off-the-shelf tools and too small for enterprise pricing.

Originally published at jmsdevlab.com

How Much Does Custom Software Actually Cost? A Straight Answer for Small Businesses

John Moore — Sat, 28 Mar 2026 23:13:44 +0000

Business owners seeking custom software pricing often encounter vague responses. This article provides concrete figures for small business software projects, ranging from €3,000 spreadsheet replacements to €25,000 full applications.

Why Most Developers Won't Give You a Straight Answer

Agencies frequently avoid transparent pricing to secure initial consultations. Hourly billing models shift financial risk to clients, as projects frequently exceed time estimates. At JMS Dev Lab, we contrast this by offering fixed-price quotes established before work begins.

Real Price Ranges for Small Business Software

Spreadsheet Replacement: €3,000 – €6,000

Organizations with oversized spreadsheets featuring multiple tabs, complex formulas, and collaborative editing challenges benefit from dedicated systems. These replacements typically deliver rapid return on investment when teams waste hours managing spreadsheet errors.

Client Portal or Dashboard: €6,000 – €12,000

Systems allowing customers or staff to access consolidated information — order status, project updates, documents, invoices — command higher investment due to authentication requirements, permission management, and system integration demands.

Custom Business Application: €12,000 – €25,000

Specialized applications addressing unique workflows — booking systems, job management tools, commission trackers, repair ticketing platforms — represent the largest category. These solutions accommodate distinctive business processes rather than forcing operations into standardized software.

What Affects the Price

Several factors influence project costs:

Business logic complexity: Simple data entry differs significantly from systems involving multivariable pricing calculations and document generation
System integrations: Connecting with Shopify, Xero, or Google Workspace introduces variable complexity
User role differentiation: Systems serving multiple user types with distinct permissions demand additional architecture
Custom reporting: Charts, exports, automated communications, and scheduled reports require extra development
Mobile functionality: Field-based teams need responsive interface design and testing

Hidden Costs Beyond the Build Price

Hosting: €5 – €50/month

Cloud infrastructure costs typically align with standard SaaS subscription expenses.

Maintenance: 10–15% of build cost annually

Software isn't "done" once deployed. Browsers update, security patches apply, and users inevitably request modifications once systems go live.

Training

While intuitive software minimizes training needs, team onboarding remains necessary, particularly for larger organizations with significant staff turnover.

Custom vs No-Code vs SaaS: Three-Year Cost Analysis

No-code platforms suit very small teams initially but demonstrate disadvantageous scaling economics. Per-user monthly charges accumulate significantly:

No-code platform (10 users): €7,200–18,000 over three years, with vendor lock-in risk

Custom software (10 users): €8,000 build plus €2,400 maintenance equals €10,400 total, providing ownership without per-user restrictions

At ten or more users, custom development typically proves financially superior while eliminating platform dependency.

Funding: The LEO Grow Digital Voucher

Irish small businesses may access the Local Enterprise Office Grow Digital Voucher, covering 50% of eligible project costs up to €5,000. A €10,000 project could reduce to €5,000 out-of-pocket expense.

Eligibility requires 1–50 employees, minimum six months operational history, and Digital for Business programme completion.

When NOT to Go Custom

Custom development isn't universally appropriate:

Generic requirements: Existing solutions (Xero for invoicing, HubSpot for CRM) serve standard business needs effectively
Minimal user base: Under three users, SaaS per-user costs typically remain economical
Undefined requirements: Inability to articulate specific problems indicates premature custom development consideration
Immediate deadlines: Custom software requires weeks to deliver; urgent needs necessitate existing platform adoption

How to Get Started

The engagement process follows three stages:

Complimentary consultation: Discuss problem statements without sales pressure
Fixed quotation: Receive transparent scope and pricing with no hidden charges
Development and deployment: Complete projects typically launch within 4–8 weeks; clients retain full code ownership

Custom software serves businesses requiring specialized solutions unsuitable for off-the-shelf platforms yet operating at scale inappropriate for enterprise pricing.

Originally published at jmsdevlab.com