DEV Community: Cameron Hayes

Most businesses don't have a productivity problem. They have a "still doing this by hand" problem

Cameron Hayes — Wed, 17 Jun 2026 06:11:34 +0000

We had a client once who had three people spending part of every Friday pulling numbers from different tools, dropping them into a spreadsheet, and emailing it to the same distribution list. Every week. Same spreadsheet. Same list. Had been going on for about two years.

When we asked why it hadn't been automated, the answer was basically: nobody had gotten around to it. The whole thing probably took four hours total across the three people. Not the end of the world on its own. But multiplied across 52 weeks, that's over 200 hours a year spent on a single report that could run on a schedule with zero human involvement.

That's the thing about manual work. It doesn't feel urgent enough to fix, so it just keeps going.

It's usually not one big thing

The businesses that struggle most with this aren't drowning in one massive inefficient process. It's more like death by a thousand small ones. An approval that takes two days because it sits in someone's inbox. Customer data that lives in three places and has to be manually kept in sync. Follow-up emails that someone has to remember to send.

None of it sounds like a crisis. But when you add it up across a team of 15 or 20 people, you're talking about a serious chunk of paid time going toward work that software could handle.

The reason most companies haven't automated these processes yet isn't that they don't know it's possible. It's that fixing it requires someone to stop and think about it, and everyone's too busy doing the manual work to stop.

What actually goes wrong when people do repetitive work

This might sound obvious but it's worth saying plainly. People are not good at doing the same thing over and over without variation. Not because they're careless but because that's genuinely how attention works. After the 50th time you've done a thing, your brain treats it as background noise. Details get missed. Steps get skipped. Not always. Not even usually. But enough that it causes real problems.

We've seen this in billing. In data migration. In onboarding checklists where one field consistently gets left blank because it's easy to overlook on step 11 of a 12-step process.

The downstream effects are almost always bigger than the original mistake. A wrong field in a customer record creates a bad email. A missed step in onboarding creates a confused customer. A billing error creates a refund conversation nobody wanted to have.

Automated processes don't solve every problem but they do eliminate this entire category of issue. The steps run in order, every time, regardless of how many times the workflow has already run that day.

Growth usually exposes this faster than anything

Small teams can absorb a lot of manual work without it becoming visible. But when a business starts growing and volume picks up, the cracks show quickly. Suddenly the same number of people are handling twice the transactions, twice the customer requests, twice the reporting. And they're doing it manually.

This is actually one of the clearest reasons to automate business processes that most teams understand immediately once they're in it. It stops being a theoretical efficiency argument and starts being a practical question of whether the team can keep up.

How to actually get started

Don't try to map every process in the business. Pick the one thing that comes up most often and takes longer than it should. Start there. Get it working. See what changes.

Most teams that go through this once want to do it again pretty quickly. The first automation is usually enough to make the case for the second one.

Bitcot has helped businesses work through exactly this kind of thing. If you want a clearer picture of where automation typically has the most impact, that's a good place to start reading.

Want to figure out what's worth automating first in your business? Get in touch.

Building APIs on AWS in 2026 Requires More Upfront Thinking Than It Used To

Cameron Hayes — Wed, 17 Jun 2026 05:49:31 +0000

Not long ago, the conversation around AWS API architecture was short. Most teams picked whatever language they knew, dropped it behind API Gateway, and moved on. The choices were forgiving enough that you could get away with not thinking too hard about them.

That window has mostly closed.

The difference between a runtime that suits your workload and one that doesn't shows up in real ways now: latency under load, infrastructure costs at scale, how long it takes your team to ship changes a year after the initial build. Getting these decisions roughly right at the start saves a lot of pain later.

Runtime choice matters more than people expect

The three runtimes that come up most in 2026 for AWS API work are Node.js with NestJS, Python with FastAPI, and Go.

NestJS works well for teams that are already deep in TypeScript and want a framework that enforces structure across a larger codebase. The framework overhead is real and cold starts on Lambda are heavier than lighter options, but for organizations where consistency across a big engineering team matters, the tradeoff often makes sense.

FastAPI has gotten genuinely strong for Python teams, especially if the API is doing anything adjacent to data processing or AI integration. The performance for async I/O workloads is solid, Pydantic validation cuts down on boilerplate significantly, and Lambda SnapStart has improved the cold start situation enough that running FastAPI serverless is now a real option rather than a workaround.

Go is fast. Cold starts are short, memory footprint is small, throughput is high. For teams already writing Go, it performs well on both Lambda and Fargate and has a real edge in latency-sensitive workloads. The catch is that it's not worth picking Go for the benchmark numbers alone. If your team doesn't already know it, the ramp-up cost eats whatever performance advantage you were chasing.

The honest answer is that the right runtime is the one your team can build and maintain confidently, within the performance constraints your API actually has. Most teams get into trouble by optimizing for the wrong variable.

Lambda vs Fargate: depends on your traffic

Lambda's serverless model is genuinely simple to operate. You deploy code, AWS handles the rest, and you pay per invocation. For APIs with unpredictable or spiky traffic, this usually works out well economically.

The problem shows up when traffic is steady and high-volume. At that point, per-invocation pricing starts looking expensive compared to a Fargate setup running containers at a fixed cost. Lambda also has execution time limits that matter for some workloads. If your API needs to do anything long-running, Lambda forces you into workarounds that Fargate handles naturally.

Fargate adds operational overhead that Lambda doesn't have. You're managing containers, task definitions, cluster resources. For teams that already work in Docker, this feels normal. For teams that don't, it's a meaningful addition to the cognitive load of a new project.

SnapStart has narrowed the gap between the two for Python and supported runtimes by reducing cold start latency, which was the main Lambda weakness. But it doesn't eliminate the cost model difference at high sustained load.

API Gateway config that's easy to skip and annoying to fix later

Authentication and rate limiting at the gateway level are worth getting right in the initial build. Doing auth inside each service instead of at the gateway means duplicating that logic across everything. Rate limiting configured after an incident is always less thoughtful than rate limiting designed upfront.

Same goes for observability. X-Ray tracing and structured logging cost little to set up initially and save a lot of time the first time something behaves unexpectedly in production.

The detailed runtime comparisons, SnapStart configuration specifics, infrastructure-as-code patterns, and the specific scenarios where each option pulls ahead are covered in depth in this guide to architecting custom APIs on AWS from bitcot. Worth reading before the architecture gets locked in rather than after.

Most RPA Projects Fail for the Same Reason. It's Not the Technology

Cameron Hayes — Tue, 16 Jun 2026 13:53:30 +0000

RPA has a complicated reputation and for good reason — the gap between what gets promised in a sales cycle and what actually happens after implementation is wide enough that a lot of organizations have become skeptical. Not because the technology doesn't work, but because the conditions for it to work don't get set up properly.

The implementations that deliver real results and the ones that become maintenance nightmares are often using the same platforms, sometimes even the same vendors. What separates them is process selection — what got automated, and whether anyone asked hard questions about it before building.

What makes a process worth automating

Not every repetitive task is a good automation candidate. The ones that hold up tend to share a few things.

Volume is the most obvious. A bot that saves eight minutes per transaction looks different at 2,000 transactions a month than at 80. At low volumes the maintenance overhead can easily exceed the time saved, and the only winner is the person who sold the implementation.

Rules matter more than volume though. RPA bots follow instructions precisely and handle nothing that isn't explicitly defined. A process where a human regularly reads context, weighs factors, or makes calls based on experience that isn't written down anywhere — that process is going to produce a lot of exceptions the bot can't handle. A process where the human is essentially doing the same thing the same way every time, just slowly and manually, is what automation was built for.

Stability is the one that tends to get underweighted. Bots interact with systems through their interfaces. When a screen changes, a field moves, or a vendor updates their portal, bots break. A process that runs against a system that changes frequently is going to require constant maintenance. A process that runs against something stable — legacy ERP, internal tooling that never gets touched — is much lower-risk to keep running.

Which specific processes across industries meet these criteria is covered in detail in this guide on who uses RPA and what they're automating.

The process selection mistake most teams make

The most expensive mistake in RPA isn't choosing the wrong platform. It's automating the process as it currently exists without asking why it works that way.

Manual processes in most organizations have accumulated steps over years that nobody questions anymore. Workarounds for system limitations that were addressed two years ago and never cleaned up. Redundant checks that made sense in a different era. Informal steps that someone added after an incident and that have just stayed. Automating all of that faithfully encodes the inefficiency into the bot. The result is something that runs faster but is still fundamentally broken.

Before automating anything, it's worth understanding which steps are genuinely necessary and which are artifacts. Sometimes that review reveals that the process itself should change before it gets automated. Sometimes it reveals that the whole thing could be eliminated with a small system configuration that nobody bothered to make. The automation project, if nothing else, forces a conversation about the process that should have happened a long time ago.

Exception handling is where pilots look better than production

Most pilots test the happy path. The transaction goes through cleanly, the data is formatted correctly, all the expected fields are populated, the downstream system accepts it. The bot handles it perfectly and the demo looks great.

Production data isn't like that.

Real data has formatting inconsistencies, missing fields, edge cases that appear rarely enough that nobody remembered to include them in the requirements. Real processes have exceptions that humans handle informally — a piece of information is missing so they check a second source, something looks wrong so they flag it rather than processing it, an unusual case shows up and they use judgment about how to route it.

When those situations hit a bot that wasn't built to handle them, one of two things happens. The bot fails loudly and someone has to investigate. Or worse, it fails silently — processes the transaction incorrectly and moves on, and nobody knows until something downstream is wrong.

Teams that map exception paths carefully before building, and design explicit handling for each one, ship bots that hold up in production. Teams that map the happy path and plan to handle exceptions later end up rebuilding significant portions of their automation after go-live.

The maintenance reality

Bots require ongoing attention. This is the part of RPA that tends to be underrepresented in ROI projections and overrepresented in the experience of organizations that have been running automation for a year or two.

Systems change. Vendors update portals. Internal applications get new releases. Processes get modified. Any of these can break a bot, and the team that built it has to fix it. At a small scale this is manageable. As the bot count grows, so does the surface area for things to break, and without deliberate operational structure the maintenance work starts crowding out new development.

The organizations that handle this well tend to build ownership into the program from the start — each bot has a defined owner, monitoring is in place to catch failures before they pile up, and there's a process for getting notified when system changes are coming rather than discovering them after a bot is already broken. None of this is complicated. It just has to be set up intentionally rather than figured out reactively after the third production incident.

The comparison of which departments have built the most durable programs and why is worth reading before building out an automation practice — this detailed breakdown of RPA adoption by industry and department covers what the successful programs have in common.

The question worth asking first

Before any bot gets built, one question is worth sitting with longer than most teams do: is automating this process solving the right problem?

Sometimes yes — the process is necessary, high-volume, rule-based, and the main issue is that it takes too much human time. Build the bot.

Sometimes the process exists because of a system limitation that could be addressed directly. Or it's redundant. Or a small workflow change could eliminate it entirely. In those cases, automation makes a problem permanent rather than fixing it.

The teams that build programs worth having ask this question consistently, for every candidate process, before writing a single line of bot logic. It slows down the start. It's why their automation is still running two years later.

The IDD Workforce Gap Is Getting Worse. Here's Why the Old Approaches Aren't Working

Cameron Hayes — Tue, 16 Jun 2026 13:07:47 +0000

Ask anyone running an IDD program about staffing and you'll usually get a pause before the answer. Not because the problem is complicated to describe, but because describing it means sitting with how bad it actually is.

Turnover in direct support work runs high — 40, 50, 60 percent annually at many organizations. People leave for a lot of reasons. The pay hasn't moved much relative to what the job actually demands. Staff get assigned to more individuals than they can realistically support well, and over time that wears on them. Some never got enough training to feel confident in the role. Others find work elsewhere that asks less of them for similar or better pay. Most of the time it's some combination.

A better job board doesn't fix any of that. But there's one part of the staffing problem — getting the right people through the door in the first place, matching them to roles where they'll actually succeed — where technology can genuinely help. In a sector where an unfilled position means someone on a waiting list or a person getting reduced support hours, that piece matters more than it might look like from the outside.

What makes IDD hiring different from most caregiving roles

The skill set for direct support work in IDD is specific in ways that general hiring platforms don't have good vocabulary for.

Someone who spent three years as a job coach supporting adults with developmental disabilities in competitive employment brings something meaningfully different from someone who worked in a nursing home or a group home serving seniors. Both have caregiving experience. The overlap in what they actually know how to do is partial, not total. In IDD work specifically, familiarity with behavioral support approaches, augmentative communication, person-centered planning, and in some roles specific certifications — these things separate candidates who can step into a position productively from those who need six months of foundational training before they're genuinely useful.

General platforms don't capture this. Their keyword matching treats "care experience" as care experience. A resume full of IDD-specific roles gets ranked the same as one without it. Organizations end up screening out the majority of applicants manually because the platform did nothing to filter for what actually matters — and that screening work falls on program directors and supervisors who have limited time for it.

The geography problem

Direct support work in IDD is almost entirely place-based. A residential support staff member works at specific homes. A job coach supports specific individuals at specific worksites. Day program roles are tied to a physical location. There's very little of this work that can be done remotely or that's flexible about location in the way some other jobs are.

This makes geographic matching not a preference but a hard constraint. Someone who looks strong on paper but doesn't have reliable transportation to get across town isn't actually a viable candidate for most of these positions, no matter how good their background is.

General platforms have location filters. What they don't have is any understanding of what community-based IDD work requires in terms of proximity, transportation access, or neighborhood familiarity. The filtering they offer is a rough approximation that still produces a lot of candidates who won't work in practice, which means more manual sorting.

What it means to hire inside the right context

Path-Now started as a platform for connecting individuals with IDD to service providers across California. The network it built was already IDD-specific — organizations, providers, families, job seekers oriented toward disability services. That existing context is what made adding a job resource section meaningful rather than just another feature.

When an organization posts a role inside Path-Now's network, they're not competing for attention alongside warehouse jobs and retail postings. The people browsing are already in an IDD-relevant context. That baseline relevance changes the quality of the applicant pool before any filtering even happens — not because the platform is magical, but because the audience is self-selected in a way that a general platform's isn't.

The design and functionality behind how Path-Now built this out — how roles get posted, how applicants move through the process, how the tool fits into the broader platform — is covered in this detailed account of the Job Resource Section.

Why matching quality affects retention too

Hiring and retention get treated as separate conversations in most workforce discussions. In IDD they're not.

Staff who were poorly matched at the point of hire — whose experience didn't actually align with the support needs of the individuals they're working with, who weren't given an accurate picture of the role before starting — leave sooner. The first six months are when turnover is most expensive, and bad matching drives a significant share of it.

Getting the match right upfront doesn't solve the pay problem or the burnout problem. But it removes one avoidable reason people leave early. Over a year, across a program, that adds up.

The actual stakes

IDD organizations aren't just trying to fill positions. They're trying to maintain stable, consistent support for people whose daily quality of life depends on who shows up and whether that person knows what they're doing.

When a program runs short-staffed for months, the people receiving services feel it. When someone leaves three months in and a new person starts from scratch building trust and learning individual routines, the people receiving services feel that too. The staffing problem and the service quality problem aren't parallel issues — they're the same issue.

What Path-Now built into its platform is one piece of a much larger problem. But it's a piece that addresses something real, in a context where the people searching already understand the work. The reasoning behind how the Job Resource Section was designed and what it was trying to accomplish is laid out in this writeup on the feature.

The Gap Between Cancer Appointments Is Where Patients Need Help Most

Cameron Hayes — Mon, 15 Jun 2026 11:30:57 +0000

Most oncology care is built around scheduled touchpoints. Infusion days, labs, imaging, follow-ups. Inside those appointments, the care team is focused and present. Outside them, patients are largely on their own.

That gap — sometimes a week, sometimes two — is where things go unnoticed. A fever that came and went. Four days of worsening fatigue that the patient didn't think to call about. Nausea that kept them from eating properly for most of a week. By the next appointment, most of that has faded into "I wasn't feeling great." The oncologist works with that because there's nothing more specific available.

A hospital-connected mobile app doesn't close this gap by adding work. It closes it by making it easy to capture what's happening in the moments when it's happening, and getting that information to someone who can do something with it.

What the care team is actually working with

Between visits, most oncology teams know what came back in labs and whatever the patient reports at their next appointment. That's usually it.

Patient recall over two weeks of treatment is unreliable — not because patients don't try, but because managing significant physical symptoms while running a household and possibly still working doesn't leave a lot of mental bandwidth for keeping detailed records. A pattern of gradually worsening fatigue doesn't get described as a pattern. It gets described as "I've been tired" with no sense of when it started or how it's been tracking.

A quick daily check-in through an app — thirty seconds, a few symptom scores, nothing more — gives the care team a picture that appointment-based reporting never will. Not a detailed health journal, just enough structure to see whether things are trending in a direction worth acting on before the patient comes in.

Oral chemo and the adherence problem nobody warned patients about

When chemotherapy moved partly into pill form, it gave patients more control over their treatment and fewer clinic visits. That's mostly a good thing.

It also meant patients managing serious medications at home, on their own, while dealing with fatigue and cognitive side effects that make remembering things harder. Whether a dose was taken becomes genuinely unclear sometimes. Timing relative to food or other medications gets missed. A cycle that requires specific spacing between doses gets approximated rather than followed precisely.

This isn't carelessness. It's what happens when you hand someone a complicated medication regimen and expect them to manage it accurately while they're sick.

A reminder tied to the actual prescribed schedule helps. Not a generic phone alarm, but something that knows which medication, which dose, and what the specific instructions are — and that records whether the patient confirmed taking it. When doses get missed consistently, the care team sees it. That's a different level of support than hoping the patient remembers to mention it.

Getting to appointments is harder than it looks from the outside

Cancer treatment involves a lot of clinic time. Infusion days, follow-ups, imaging, specialist visits. For patients who live any distance from a comprehensive cancer center, this is a real burden — the drive, the parking, the waiting, the physical effort of getting there when treatment fatigue is significant.

A lot of follow-up appointments are essentially conversations. How are you feeling, what are the labs showing, here's what we're watching for. Those don't require a physical exam. They can happen on a screen, and for someone who spent the previous day struggling to get off the couch, that matters.

Video consults work better in an oncology context when the app facilitating them is the same one where the patient has been logging how they've been feeling. The physician gets on the call having already looked at two weeks of symptom data. The appointment starts from somewhere useful instead of spending the first several minutes reconstructing what's been happening since the last visit.

How video consults, symptom logging, medication tracking, and EHR integration fit together in a working oncology app is covered in this detailed guide on hospital cancer patient app design.

Caregivers are part of this whether the app knows it or not

Most patients going through cancer treatment have someone helping them. A partner managing the medication schedule. A parent tracking appointments. An adult child coordinating between providers. That person is doing real care work and usually doing it with limited information — whatever the patient remembers to share, whatever they were in the room for.

Building caregiver access into a hospital oncology app, with consent controls and appropriate privacy boundaries, makes the whole system more functional. The medication schedule isn't just on the patient's phone. The appointment calendar is shared. When something changes in the care plan, the person helping manage daily life knows about it too.

It's a feature that gets underweighted in product discussions and overweighted in actual patient experience.

Why a third-party app doesn't solve this

Pointing patients to a general health app avoids the technical work of building something hospital-integrated. The adoption rates for that approach tend to be poor, and the clinical value tends to be close to zero.

The reason is straightforward. An app that can't connect to what the hospital knows about the patient is working with whatever the patient enters manually. The prescribed regimen, the scheduled appointments, the lab results — none of that comes through. The care team has no reason to look at it because nothing from the app feeds back to them.

Hospital integration is what makes the tool worth building. It's also what makes the build harder — EHR connectivity, HIPAA compliance at every layer, clinical workflow integration that care teams will actually trust. The technical requirements for getting this right are covered in this guide on hospital-integrated oncology app development.

The between-appointment period is where patients spend most of their time in treatment. Building something that supports them there — and keeps the care team informed — is the actual job.

Building a Health Data Aggregator App Is Harder Than It Looks From the Outside

Cameron Hayes — Mon, 15 Jun 2026 09:08:38 +0000

Everyone who has sat with a new doctor and spent fifteen minutes recounting medical history that already exists somewhere understands the problem this kind of software is trying to solve. The records are out there. They're just not together.

Getting them together is where things get complicated.

Most teams building aggregators hit the same wall within the first few months — vendor integrations that take three times longer than budgeted, patient matching that works fine until it doesn't, a compliance layer that turns out to be its own engineering project. The idea is straightforward. The implementation is not.

The EHR integration problem in practice

FHIR helped. Before it, connecting to a new health system was largely custom work every time — different APIs, different data structures, different auth flows, different everything. FHIR gave the industry a common enough API pattern that building reusable connectors became realistic.

The problem is that "FHIR certified" covers a lot of ground. Spend time actually integrating two different EHR vendors and you'll find they've made different choices in how they implemented the standard. Rate limits that aren't documented. Sandbox environments that behave differently from production in ways you only discover when real patient data starts flowing. Error responses that don't match what the documentation says they'll look like.

And that's before getting into the systems that never moved to FHIR at all. A lot of clinical data — labs, imaging, older hospital systems — still lives behind HL7 v2 interfaces. Skip those and you're skipping real patient history that clinicians actually need. Which means anyone building a serious aggregator has to handle both, and maintain those connectors over time as vendors push changes on their own schedule.

Patient matching: the part that always takes longer

Matching records across systems — confirming that the same patient appears in multiple EHRs — sounds like a solved problem. It's not.

Synthetic test data is well-behaved. Real registration data has been entered by staff across many different facilities, over many years, with inconsistent validation and inconsistent mandatory fields. A name spelled three different ways across three different systems. A date of birth entered incorrectly at one hospital and never corrected. A patient who legally changed their name, with some systems updated and others not.

Probabilistic matching gets you somewhere — you're scoring likelihood across multiple fields rather than requiring exact hits. But you still have to pick a confidence threshold, and the right threshold in a healthcare context is different from almost any other domain. Too tight and you miss real matches, leaving a patient's history fragmented. Too loose and you start connecting records that belong to different people, which in a clinical setting isn't just a data quality problem — it's a patient safety one.

Most teams building this for the first time set their threshold based on what worked in testing, discover it doesn't hold in production, and spend the next few months tuning it. The ones that hold up better are the ones that stress-tested against genuinely messy real data before launch, not after.

The compliance work that gets underestimated

Encryption, access controls, audit logging — anyone building in healthcare knows these going in. The compliance work that tends to get scoped too narrowly is what sits above that: consent tracking and data use governance.

Patients have different consent statuses for different purposes. Some have opted out of data sharing for research. Records in behavioral health, substance use, and reproductive care carry additional legal protections that go beyond standard HIPAA requirements. An aggregator that ingests all of this and then surfaces it without enforcing consent rules at query time — not just at ingestion — isn't actually compliant in any meaningful way.

Getting this right requires understanding early on who will be querying what data and why. That's partly a product question, not just a technical one, and it needs to be settled before the architecture is built. Retrofitting a consent layer into a system that wasn't designed for it is expensive and messy.

The specific technical decisions involved in building this well are covered in detail in this guide on health data aggregator challenges and best practices — including how the architecture should be structured to make governance tractable at scale.

Making the ROI case

The internal justification for health data aggregation usually focuses on clinical outcomes — catching drug interactions, reducing duplicate testing, improving care coordination. These are real benefits and they're meaningful. They're also slow to measure and hard to attribute directly to the aggregation layer, which makes them difficult to re-justify at budget review time.

The ROI arguments that hold up better in practice are operational. Fewer hours spent on manual record requests. Faster prior authorization because the complete clinical picture is available. Care gaps caught earlier because a result from a system nobody knew to check is now surfaced automatically. These are more concrete and more attributable, and building the measurement framework for them from day one makes the business case more durable.

What actually makes a build work

The aggregators that earn clinical trust share some characteristics that don't appear in a product spec.

They got real data into the system early — not synthetic records, actual messy patient data — and used it to stress-test matching and normalization before launch rather than after. The teams that did this rewrote parts of their matching logic based on what they found. The teams that didn't found the same issues in production.

They scoped normalization as its own engineering concern with its own timeline and iteration cycle, separate from the main pipeline work. The ones that treated it as a module to build alongside everything else discovered post-launch that query results across sources weren't comparable in ways that damaged clinical confidence in the data.

And they built operational tooling from the start — monitoring that detects when a source system changes behavior, alerts when match rates shift unexpectedly, investigation tools that don't require a full redeploy to use.

For teams working through the architecture decisions, the detailed breakdown of health data aggregator app challenges, solutions, and best practices is worth reading before the build starts.

The "Fix or Rebuild" Question Has a Hidden Third Option Nobody Talks About

Cameron Hayes — Mon, 15 Jun 2026 07:32:18 +0000

Every SaaS team eventually has the argument. Something is broken enough that patching it is starting to feel like losing. Someone says rebuild. Someone else says the rebuild will take too long and cost too much and they'll never get sign-off anyway. The conversation stalls. Another patch ships.

What usually gets lost is that "fix it" and "rebuild it" aren't really two options. They're two ends of a spectrum, and the right answer is almost always somewhere in the middle — a targeted, scoped intervention that doesn't require taking the whole product offline and starting over.

Getting there requires being specific about what's actually broken and what it's actually costing. Most teams skip that part.

The cost of fixing that nobody tracks

When teams argue for fixing over rebuilding, the case usually goes: cheaper, less risky, keep shipping while you do it.

Sometimes that's right. But it assumes the fix is addressing the actual problem rather than what's visible on the surface.

A new engineer joins and spends six weeks just getting oriented — not learning the product, but learning why the codebase works the way it does and which things are safe to touch. Nobody counts that as a cost of technical debt, but it's real time that got absorbed. Then there's the fix that goes out on a Tuesday and by Thursday someone's filed a bug in a completely different area that shouldn't have been affected. Debugging that takes another two days.

Over time this just becomes the background hum of the engineering team. Things take longer than they should. Estimates stop being trusted because they keep being wrong. Eventually people stop giving estimates at all and just say "it depends."

That's not a people problem. It's what happens when the system is fighting you and nobody's done anything about it.

What rebuild estimates always get wrong

Rebuilds go over budget for reasons that are pretty consistent across projects and have nothing to do with the team underperforming.

Scope is the big one. You start with a clear target — the payments module, the data pipeline, the authentication layer — and somewhere around week four you discover that six other things are tightly coupled to it in ways that weren't obvious from the outside. Now the decision is either patch those connections into the new system or bring them along for the rebuild. Neither answer is clean.

Then there's migration. Teams plan the rebuild but underplan the transition. Moving live customer data from an old schema to a new one, without downtime, in a way you can roll back if something goes wrong — that's often more work than building the new system itself. It's also the part that can go most visibly wrong in front of customers.

And there's the stuff that genuinely doesn't make it into any budget: the deals in the pipeline during a long rebuild period, the features competitors shipped while your team was heads-down, the customer who churned three months in because the thing they'd been waiting for kept getting pushed back.

Rebuilds cost more than estimated almost universally. Not because the estimates are careless, but because "what the rebuild involves" turns out to be bigger than it looked from the outside.

Bitcot breaks down the actual cost comparison between rebuilding and fixing SaaS products in detail, including how AI-driven development changes the numbers on both sides. Worth reading before you take either option to the board.

Where AI shifts things

AI doesn't resolve the fix-or-rebuild question. But it does move some of the numbers.

On the rebuild side — the phases that used to eat the most calendar time before any visible progress happened are exactly where AI tooling helps most. Mapping the existing codebase, surfacing undocumented dependencies, generating test coverage for the old system before migration, scaffolding the new architecture. Work that used to take a senior engineer a month now takes a week or two. That's not a minor change when you're trying to make the rebuild timeline defensible.

On the fix side — AI code analysis can tell you which parts of the system are actually causing the drag, not just which ones look messy. That makes targeted fixing more precise. Instead of a vague "let's clean up the codebase" project that spreads across six months, you can make a specific case for addressing specific problems with specific expected outcomes.

Neither of these is a magic answer. But they do change the inputs to the decision.

Why this decision keeps getting made badly

Most fix-or-rebuild decisions get made in reaction to something. A production incident. An engineer quitting. A sales call where a prospect asked about a capability the system can't support. The decision gets made under pressure, with incomplete information, and with one eye on how long either option will take to get approved.

That's how you end up in a rebuild that mushrooms into something twice the original scope, or in a fix cycle that runs two years and leaves the underlying problem untouched.

The teams that make this decision well usually do one thing differently: they diagnose before they decide. Not a long drawn-out audit, but a real look at which parts of the system are the actual source of the pain versus which parts are just symptoms. That distinction determines whether fixing makes sense or whether you're putting money into something that's going to hit the same ceiling again in eighteen months.

That diagnosis is the part worth protecting time for, even when everything feels urgent. For a more detailed look at how the cost comparison actually plays out and what role AI plays in either path, Bitcot's breakdown of SaaS rebuild vs. fix costs is a practical starting point.

Your Team Is Working Hard. RPA Is Why They're Still Falling Behind.

Cameron Hayes — Mon, 25 May 2026 07:19:45 +0000

There's a specific kind of exhaustion that settles into operations teams that are doing everything right and still can't keep up. The team isn't slow. They're not making unusual mistakes.They're just spending a disproportionate amount of every day doing things that follow a predictable pattern — copying data from one system to another, checking fields, filling forms, generating reports that are going to look exactly like the report from last week.

The work isn't hard. It's just endless. And it compounds in ways that are hard to see until you step back and look at where the hours actually went.

What RPA Is, Without the Hype
Robotic Process Automation is software that does what a human does when they're working in a digital system — clicking through screens, reading data, entering fields, moving information between applications. It follows rules.

It won't handle something it wasn't built for. If an edge case shows up that the bot's rules don't cover, it either fails or routes to a human — which is actually fine, because that's what should happen. The important thing to understand is that RPA isn't trying to think. It's trying to do the same thing correctly, every time, without getting tired or distracted. That's a narrow capability and a genuinely useful one for the right type of work.
The processes where it works are the ones eating most of your team's time right now.

The Invoice That Takes Thirty Minutes to Process
Finance teams know this well. Walk through what actually happens when an invoice lands in a finance team's inbox. Someone opens it. They check the vendor name against the system. They pull up the purchase order and verify the amount matches. They type the line items into the accounting platform. They figure out which approval threshold applies and route it to the right person. They log it somewhere so there's a record. On a good day with a clean invoice that's maybe twenty-five minutes. On a day with a discrepancy, longer.

At fifty invoices a week that's manageable. At two hundred it's most of someone's job. At five hundred it's a team of people doing work that follows the same rules every single time, and the error rate at that volume — even with a careful, capable team — is probably sitting somewhere between 2% and 5%.

An RPA bot handles this sequence automatically — reads the invoice, validates the fields, enters the data, routes for approval based on the amount. It runs the same rules on invoice number two hundred as it did on invoice number one. The error rate doesn't creep up as the day goes on. The processing time doesn't slow down after lunch.

The Onboarding Process That Runs on Emails
HR teams spend a significant amount of time on work that is genuinely important but genuinely repetitive. A new employee joins. Access needs to be provisioned across multiple systems. Benefit enrollment materials need to go out. Documents need to be collected, reviewed, and filed. Equipment requests need to be submitted. IT needs to be notified.

Most of this happens through a combination of emails, checklists, and calendar reminders maintained by people who also have fifty other things to do. The process is mostly fine. Things occasionally fall through. Onboarding experiences are inconsistent because each one depends on whoever is managing it that week.

An automated onboarding workflow triggers every step the moment the new hire's record is created. Access provisioning requests go out immediately. Enrollment materials go to the right person on the right schedule. Documents are tracked automatically. The experience is consistent regardless of how busy HR is that week or who is covering while the usual person is on leave.

Where the Real Productivity Gains Actually Come From
The numbers cited for RPA — 40 to 75% reductions in processing time, error rates dropping to near zero — are real, but they only tell part of the story. The more significant change is what happens to the people who were doing the work.

A finance analyst who isn't processing invoices for three hours a day has three hours for actual analysis. An HR coordinator who isn't manually triggering onboarding tasks has time for the conversations with new employees that actually determine whether those people feel welcomed into the organisation. A customer service team that isn't looking up account information manually can focus on the interactions that require empathy and judgment rather than data retrieval.

The productivity gain isn't just speed. It's the reallocation of human attention toward work that actually benefits from human attention.

Finance, HR, Customer Service, Supply Chain — The Pattern Is the Same
The processes that consistently deliver the strongest RPA returns share three characteristics. They happen frequently. They follow clear rules. They currently require someone to spend meaningful time on them.

Invoice processing and account reconciliation in finance. Onboarding, benefits administration, and payroll validation in HR. Ticket routing, status updates, and account lookups in customer service. Order processing, inventory updates, and shipping notifications in supply chain and eCommerce.

Each of these is a place where a human is currently acting as a bridge between systems — taking information from one place and putting it somewhere else according to rules that don't change. The bot does the same thing, faster, without the error rate that accumulates when humans do the same thing hundreds of times.

The Step That Determines Whether It Works
Most RPA implementations that don't deliver trace back to the same decision made early in the project — automating a process before understanding it.

The process as described in a requirements meeting is almost never the process as it actually runs. There are exceptions that get handled informally. There are steps that depend on someone's judgment about a specific vendor, a specific customer, a specific situation. There are edge cases that happen often enough to matter but not often enough to make it into the documented workflow.

Build a bot against the documented workflow without mapping what actually happens and you get a bot that works most of the time and breaks on everything else. Then you have automated failure at scale rather than manual failure at human speed.

The time spent mapping a process fully — including the exceptions, the informal handling, the things that everyone does but nobody has written down — is the work that determines whether the automation is reliable. It's not glamorous and it often takes longer than expected. It's also what separates the RPA deployments that deliver consistent value from the ones that create a different category of maintenance problem.

Starting Small Is the Right Call
The temptation when an organisation commits to automation is to scope broadly — pick five processes, build them all, see the results across the whole operation at once. In practice this usually means five processes each built with less scrutiny than any single one of them would have received on its own.

Starting with one process — the highest-volume, best-understood, most rule-based process in the organisation — and doing it properly creates something more valuable than a wider deployment done carelessly. One bot that runs reliably is more valuable than five that need babysitting. The team knows what it does, they trust it, and they have actual before-and-after numbers to show for it. Then when the second one gets built, the people doing the work already know what a thorough process map looks like, they know which edge cases tend to hide until the last minute, and they know how to set up monitoring that catches problems early. Each one that works makes the next one faster to build and easier to get right.

What Comes After RPA
Classic RPA handles structured data. A form with consistent fields, a system that always returns data in the same format, a process where every input looks roughly like every other input. This covers most of what currently consumes operations team time.

Not everything fits neatly into rules. A vendor who sends invoices in a completely different layout every time. A customer support email that needs someone to actually understand what the person is asking before anything can happen with it. A form that was filled out by hand, scanned, and arrived as an image file with no extractable text. Standard RPA hits a wall with these because the inputs are unpredictable and a rule-based system needs predictability to work.

That's where adding an AI layer starts to make the difference — handling the unstructured inputs that classic RPA can't read, then passing the extracted, structured data into the same bot workflows that already exist. For most organisations, that's further down the road. The immediate priority is the structured, rule-based, high-volume work that the team is handling manually right now — and that's plenty to start with.

The full picture of where RPA delivers the strongest results — by function, by industry, and by implementation approach — is where the decision about what to automate first becomes a lot clearer. The team that's currently falling behind despite working hard isn't doing anything wrong. They're just still doing things that software should be doing for them.

Microsoft Power Pages Consulting & Development

Cameron Hayes — Tue, 28 Apr 2026 10:54:51 +0000

Most businesses are still handling external data requests the slow way — emails, manual exports, status calls that eat up someone's afternoon. The data exists. Getting it to the right people securely is the actual problem.

Microsoft Power Pages is built specifically for that gap. It sits on top of your existing Microsoft environment — Dataverse, Dynamics 365, SharePoint — and lets you give customers, partners, or vendors controlled access to real business data through a clean web portal. Not a copy of the data. The actual records, in real time.

The security model is solid. Table permissions let you control exactly what each user can see or edit. Authentication runs through Microsoft Entra, so there's no separate login system to manage.

On the build side, you can get something functional up in days using the low-code Design Studio. For anything more specific, custom code fills the gaps without starting from scratch.

It works best for teams already in the Microsoft ecosystem. If that's you, it's worth a closer look at Microsoft Power Pages development services to see what a full implementation actually involves.