Every January I watch small business owners get handed a technology roadmap that looks impressive and dies by February. Twenty slides, twelve initiatives, a Gantt chart nobody opens again. Technology planning for small business does not need any of that. It needs one page, three priorities, and someone whose job it is to check on them.
I have sat through both versions: the consultant deck that gets filed away, and the scrappy list on a whiteboard that actually gets done. The whiteboard wins every time, because it matches how a 15-person company actually operates. You do not have a PMO. You have an owner, maybe an ops manager, and a handful of people who are already busy running the business.
So skip the resolution-style plan. Build something you can hold yourself to in June, not just in the excitement of week one.
Why does the 20-slide roadmap fail?
The 20-slide roadmap fails for a boring reason: nobody re-reads it after the kickoff meeting. It gets written once, presented once, and then operations reality takes over, a new customer complaint, staff turnover, a supplier problem, and by March the roadmap is a fossil.
The deeper issue is that most roadmaps confuse activity with priority. A slide with twelve initiatives implies all twelve matter equally. They don't. In a small business, if you try to move on more than two or three fronts at once, none of them get enough attention to actually finish. Half-finished technology projects are worse than no project at all: you paid for them and got no result.
I have seen half-finished technology projects do more damage to a small business than no project at all, the money is spent and there is still nothing to show for it.
What does the one-page plan look like?
The one-page plan is the format I use with owners: three priorities, each with a named owner, a budget ceiling, and one measurable outcome, all fitted onto a single page, ideally something taped near your desk or pinned in a shared drive, not buried in a folder.
Three priorities, no more. Each one gets:
- A one-sentence problem statement (not a solution statement)
- A named owner, a real person, not "the team"
- A rupiah budget ceiling
- A single measurable outcome for the year
For example, a retail chain in Tangerang I worked with picked these three for the year: consolidate inventory across five branches into one system, cut phone-order handling time in half, and get basic sales reporting that the owner can check from his phone. That's it. No CRM overhaul, no AI chatbot, no website redesign, even though all three were tempting.
Pick priorities that fix pain, not priorities that sound modern
The trap in January is picking initiatives because they sound current: "we should have AI," "we need a mobile app." Ask instead: what cost us the most time or money last year? What did we apologize to a customer for, more than once? Those are your priorities.
A simple filter: for each candidate initiative, ask whether a freelancer could not fix it in under two weeks. If a two-week freelancer engagement solves it, it's not strategic, it's a task, do it now and don't let it eat one of your three slots. Reserve the three priority slots for things that need sustained ownership across months: a new core system, a process redesign, a data cleanup that touches every department.
Budget in ranges, not fantasy numbers
Small business technology budgets go wrong in two ways: owners either guess a number with no basis, or they get a vendor quote and treat it as gospel with zero buffer. Both cause the plan to collapse mid-year.
Instead, budget in ranges based on what similar-sized projects have actually cost:
| Priority type | Typical range (IDR) | Typical timeline |
|---|---|---|
| Process fix / internal tool | 30M - 80M | 6-10 weeks |
| Core system replacement (inventory, POS, booking) | 80M - 250M | 3-6 months |
| Customer-facing platform (app, portal) | 150M - 400M | 4-8 months |
Add 20% buffer to whatever range you land on. If you cannot afford the low end of a priority plus buffer, it is not a priority for this year, it goes on next year's list. This single discipline, saying "not this year" out loud, is what separates plans that survive from plans that die under budget pressure in Q2.
What keeps the plan alive after quarter one?
The plan stays alive through a 30-minute meeting every quarter, not because the document itself is good enough to survive on its own. Four times a year, the owner sits down with whoever owns each priority and asks three focused questions per priority:
- Is this still the right priority, given what changed this quarter?
- Are we on budget, and if not, why?
- Do we kill it, keep it, or escalate it?
That third question matters. Small businesses rarely kill failing initiatives, they let them limp along consuming money and attention. Give yourself explicit permission, in writing, to kill a priority at the quarterly check if it's not delivering. That permission is what makes the plan trustworthy instead of aspirational.
If you're earlier than this, meaning you haven't picked your starting point yet, it's worth reading where to actually start with digital transformation before you lock in three priorities you're not ready to execute.
Takeaway: write less, check more
A technology plan for a small business should be boring to read and hard to ignore. One page. Three priorities. A named owner and a rupiah ceiling on each. A quarterly 30-minute check with real permission to kill what isn't working. That's the whole system. If you want a second pair of eyes on picking the right three priorities for your specific business, that's exactly the kind of conversation worth having before you commit the year's budget.
