DEV Community: Nica Furs

When a firmware bug leads to millions in stolen Bitcoin: what the Coldcard incident teaches us about SSDLC and random number generation

Nica Furs — Wed, 05 Aug 2026 09:52:21 +0000

On the night of July 31, approximately 500 Coldcard hardware wallet owners reportedly lost a combined 594.48 BTC (worth around $38.2 million) after attackers exploited a vulnerability affecting seed phrase generation. The incident was first highlighted by blockchain analytics platform Lookonchain.

Following the reports, Coinkite, the company behind Coldcard, acknowledged that the issue was related to the wallet firmware and warned users to update affected devices immediately. While the company stopped short of confirming that customer wallets had been directly compromised, it admitted that certain firmware versions could generate vulnerable recovery seeds.

According to Coinkite, the flaw affects all Mk3 firmware versions starting with 4.0.1. It also impacts seed phrases generated on Mk4 and Mk5 devices running firmware earlier than version 5.6.0, as well as Coldcard Q devices prior to version 1.5.0Q. Users were urged to update their firmware and migrate funds generated using potentially affected seed phrases.

The Coldcard incident raises two critical cybersecurity questions:

How can weaknesses in the Secure Software Development Lifecycle (SSDLC) result in multi-million-dollar financial losses?
Why is cryptographically secure random number generation essential for protecting private keys and seed phrases?

How a firmware bug turned into a multi-million dollar theft

The Coldcard incident demonstrates that a hardware wallet does not need to be "hacked" in the traditional sense for users to lose their funds. Sometimes, the weakest link isn't the blockchain itself, it's the software used to generate the wallet's cryptographic secrets.

Public reports indicate that the vulnerability affected seed phrases generated on Coldcard Mk3 devices running firmware 4.0.1 and later, as well as newer models until patched firmware versions became available. Users were advised to update immediately and move their assets to wallets created with secure firmware.

Although estimates of the total damage vary, publicly available reports consistently mention hundreds of stolen Bitcoin, losses worth tens of millions of dollars, and approximately 500 affected wallets.

From an SSDLC perspective, the issue was never just a single programming bug. The larger problem is that a security-critical cryptographic function appears to have passed through development, testing, and release without sufficient verification.

If rigorous validation of entropy sources, regression testing, and independent security reviews are missing during development, a flaw in seed generation can silently make its way into production. For products designed to protect digital assets, even a seemingly minor defect can translate directly into catastrophic financial losses.

In a mature Secure Software Development Lifecycle (SSDLC), security should be integrated into every stage of development, from requirements gathering and architecture design to code review, testing, deployment, monitoring, and incident response.

Based on publicly available technical analyses, the Coldcard issue originated in the firmware's key generation process is a component that should arguably receive the highest level of cryptographic scrutiny. When security depends on a random number generator, traditional unit tests alone are not enough. Teams should also implement property-based testing, dependency verification, threat modeling, and independent security audits.

The practical lesson for security architects and software engineers is straightforward: any code involved in generating private keys, seed phrases, nonces, digital signatures, or entropy should be treated as a maximum-risk component.

This means introducing dedicated security gates, prohibiting silent fallback mechanisms, and continuously verifying that the device is actually using its intended source of true randomness instead of unintentionally relying on a software-based pseudo-random number generator. Otherwise, even a well-designed product can become a long-term vulnerability waiting to be exploited.

Where the SSDLC breaks down

The Coldcard incident highlights a fundamental SSDLC principle: security failures are rarely caused by a single bug, they are usually the result of weaknesses throughout the development lifecycle.

For security-critical products, every phase of development should include rigorous controls. Requirements should clearly define cryptographic assumptions, architectural reviews should validate trust boundaries, code reviews should focus on security-sensitive components, and testing should extend beyond functionality to verify the integrity of cryptographic operations.

Public analyses of the Coldcard vulnerability suggest that the issue originated within the firmware's seed generation mechanism. This is precisely the type of functionality that demands the strictest level of scrutiny. A component responsible for generating wallet seeds should never rely solely on conventional unit testing. Instead, development teams should implement property-based testing, dependency verification, threat modeling, and independent security audits to ensure that cryptographic guarantees hold under all conditions.

For organizations building wallets, HSMs, or any product handling cryptographic secrets, the takeaway is clear: any code responsible for private keys, recovery seeds, nonces, digital signatures, or entropy generation must be treated as a high-risk security boundary.

Dedicated security gates should be enforced before release. Silent fallback mechanisms should be prohibited, and automated verification should continuously confirm that the intended hardware entropy source is actually being used rather than an unintended software-based pseudo-random number generator (PRNG).

Without these safeguards, even an otherwise mature product can carry a hidden vulnerability that remains dormant until attackers discover and exploit it.

Why random number generation is everything

The security of a cryptocurrency wallet ultimately depends on one simple principle: a private key must be impossible to predict.

That unpredictability comes from entropy, the randomness used to generate seed phrases and cryptographic keys.

According to public analyses of the Coldcard incident, the firmware bug significantly reduced the amount of entropy available during seed generation. Some reports estimate that entropy dropped to approximately 40 bits on affected Mk3 devices and around 72 bits on other impacted models, far below the level expected for securely generated wallet seeds.

The practical implication is enormous.

Instead of facing an astronomically large search space that would be computationally impossible to brute-force, an attacker only needs to search through a dramatically smaller set of potential keys. Given sufficient computing resources and time, what should be a theoretical impossibility becomes a feasible offline attack.

This class of vulnerability is particularly dangerous because nothing appears unusual to the user.

The wallet still generates a recovery phrase.

The familiar list of words is displayed.

The overall user experience remains unchanged.

Yet beneath the interface, the cryptographic foundation has already failed.

If a wallet unintentionally relies on a weak pseudo-random number generator (PRNG) instead of a properly functioning True Random Number Generator (TRNG) or if a flaw in a function such as rng_get() causes entropy to be generated incorrectly is the resulting private keys are no longer truly random. Instead of searching an effectively infinite key space, an attacker can narrow the possibilities to a predictable subset and perform an offline search until the correct key is found.

In cryptography, this is a catastrophic failure. No amount of polished user experience or hardware security can compensate for weak randomness at the point where private keys are created.

Public technical reports indicate that the root cause lay within the seed generation pipeline, where the hardware entropy source did not behave as intended and portions of the implementation relied on software-generated pseudo-random values. Several analyses associate this behavior with firmware version 4.0.1 on the Mk3, with similar issues affecting later device families until patched releases became available.

The consequence is straightforward: a seed phrase that should have been cryptographically unpredictable became mathematically predictable.

What exactly went wrong?

From an attacker's perspective, this type of vulnerability represents an ideal scenario.

There is no need to physically compromise the hardware wallet, bypass the PIN, steal the recovery sheet, or intercept network traffic. Instead, the attacker can perform an offline brute-force attack against a dramatically reduced key space until the correct private key is found. Once recovered, the associated Bitcoin can be transferred without ever interacting with the victim's device.

This is why a flaw in a wallet's random number generation should never be viewed as "just another software bug." It undermines the very foundation of the wallet's security model.

Unlike vulnerabilities that require complex exploitation chains, a weakness in entropy affects every cryptographic secret generated during the vulnerable period. Once those secrets become predictable, every security mechanism built on top of them effectively collapses.

How to prevent it from happening again

For products that rely on cryptography, security controls around randomness should be treated as a first-class engineering requirement rather than an implementation detail.

First, the entropy source must be validated independently of the surrounding business logic. Its implementation should be reviewed during both architecture reviews and threat-modeling exercises to ensure that cryptographic assumptions remain valid throughout the system.

Second, silent fallbacks from a True Random Number Generator (TRNG) to a pseudo-random number generator (PRNG) should never occur without explicit security approval, monitoring, and alerting. If the primary entropy source fails, the system should fail safely rather than silently generating weaker cryptographic material.

Third, the release process should include dedicated verification of cryptographic invariants, including:

sufficient entropy during key generation;
the absence of predictable internal states;
verified versions of cryptographic dependencies;
reproducible builds to ensure software integrity.

For hardware wallets and HSM-compatible solutions, independent external security audits should be considered mandatory rather than optional. Responsible disclosure programs and transparent vulnerability reporting can significantly reduce the likelihood that critical flaws remain undiscovered for years before causing widespread financial damage.

Finally, wallet vendors should provide users with secure mechanisms for adding their own entropy, regenerating wallet seeds when necessary, and safely migrating assets whenever a cryptographic weakness is discovered.

Security is not a one-time process, it is an ongoing commitment

At INWAY AG, the company behind IronWallet, we consider independent verification and continuous security reviews a fundamental part of our development process. Our wallet infrastructure undergoes regular security audits conducted by independent third-party cybersecurity companies to identify potential weaknesses before they can become real-world risks.

In addition to external audits, our Security Council meets on a weekly basis to review potential vulnerabilities, analyze emerging threats, and evaluate security improvements across the product ecosystem. This approach allows us to continuously monitor risks, challenge existing assumptions, and strengthen the security mechanisms protecting our users' assets.

For a non-custodial wallet, where users maintain full control over their private keys, security cannot rely only on the strength of cryptographic algorithms. It requires a proactive security culture, continuous testing, independent reviews, and a development process where potential vulnerabilities are identified and addressed as early as possible.

At IronWallet, we believe that transparency and continuous improvement are essential principles for building trust in the cryptocurrency industry.

Key takeaways

The Coldcard incident serves as a reminder that cryptographic security depends on far more than strong encryption algorithms. Even when the underlying cryptography remains mathematically sound, a seemingly minor implementation flaw can compromise the entire security model.

Two lessons stand out.

First, Secure Software Development Lifecycle (SSDLC) practices are not simply a matter of compliance—they are essential safeguards against real financial losses. Security-critical code must undergo continuous verification throughout the entire development lifecycle, from design and implementation to testing, release, and post-deployment monitoring.

Second, the quality of random number generation is fundamental to cryptographic security. Weak entropy can transform theoretically unbreakable keys into predictable ones, allowing attackers to recover private keys without exploiting the blockchain or physically accessing a user's wallet.

In cryptography, randomness is not merely another implementation detail.

It is the foundation upon which every other security guarantee is built.

Note: The technical discussion in this article is based on publicly available reports and third-party analyses of the Coldcard firmware vulnerability. At the time of writing, Coinkite has acknowledged the firmware issue and released patched versions, while some details regarding the scope of exploitation and financial losses remain based on independent investigations rather than official confirmation.

Why Adding Developers Does Not Always Increase Engineering Capacity

Nica Furs — Fri, 31 Jul 2026 10:57:27 +0000

Engineering demand often grows faster than the team can absorb it. AI features compete with platform work, security fixes, reliability issues and product commitments for the same people. Recruitment helps only when the delivery model can support a larger team.

As systems expand, work spreads across more services, repositories, dependencies and environments. New engineers need time to understand the architecture and require input from experienced team members before they can contribute independently. Poor ownership, slow reviews and weak documentation can absorb much of the added headcount.

The practical goal is to increase engineering capacity, not simply payroll. That means shipping valuable work at a steady pace while protecting code quality, system reliability and maintainability. Where local hiring is too slow or the required expertise is narrow, companies can hire remote developers to take ownership of a defined technical scope.

Headcount Is an Input, Not the Outcome

Two teams with the same number of engineers can produce very different results. One may deploy several times a week with few incidents. Another may spend most of its time resolving dependencies, waiting for approvals and recovering from releases.

Measure Headcount Engineering capacity

Primary focus Number of engineers Useful, reliable technical output

Common metrics Team size and open roles Lead time, deployment frequency
and reliability
Main constraint Hiring speed and payroll Dependencies, technical debt and
coordination

Headcount still matters. A team needs enough people to maintain systems and deliver planned work. The problem starts when leaders treat every delivery issue as a staffing issue.

Check the Delivery System Before Opening More Roles

When delivery slows, the constraint may be elsewhere:

unclear ownership of services;
too much work in progress;
long code-review queues;
manual testing and deployment;
poor documentation and slow onboarding;
technical debt that makes small changes risky;
dependencies that require several teams to coordinate.

Every new team member needs context, access, reviews and decisions from people who are already busy. The result may be more activity without a meaningful improvement in lead time.

Before hiring, trace how a change moves from idea to production. Where does it wait? Which approvals are repeated? Which systems can only be changed by one or two people? These questions usually reveal the real capacity limits.

Team Design Determines How Much Capacity You Keep

High-performing teams reduce the coordination required for routine work. That starts with clear ownership. A team responsible for a defined product area or service can make decisions faster than a group that depends on several departments for every change.

Automation removes work from the release cycle that does not require engineering judgement. Builds, tests, provisioning and deployment checks can run through the delivery pipeline, while production monitoring helps teams trace failures faster.

Documentation covers another common bottleneck. When service boundaries, operational procedures and system dependencies are recorded properly, new engineers need less day-to-day guidance from senior staff.

Capacity also depends on architecture. A tightly coupled system forces teams to coordinate even for small changes. Clear interfaces and service boundaries allow work to proceed more independently.

Useful capacity metrics include:

lead time for changes;
deployment frequency;
change failure rate;
mean time to recovery;
escaped defects;
service reliability.

DORA’s software delivery performance metrics similarly focus on delivery speed, deployment frequency, change failures, recovery and rework.

These measures show whether the delivery system is becoming faster and safer or simply busier.

Flexible Scaling Works When the Operating Model Is Ready

Permanent hiring is not always fast enough for a product launch, migration, security project or AI initiative. Remote engineers can add specialist knowledge and delivery capacity without requiring every capability to be built internally.

The model works best when external engineers join the same operating system as the internal team. They should use the same repositories, planning process, coding standards, security controls, documentation practices and definition of done.

Flexible scaling is less effective when responsibilities are vague. Adding people to an unowned backlog or unstable architecture usually creates more coordination work. A clear workstream, accountable technical owner and measurable outcome make the arrangement easier to manage.

A distributed talent model can fill capability gaps that are difficult to cover through local recruitment. Cloud engineers, data specialists, DevOps practitioners, cybersecurity experts and legacy modernisation teams can be added around a specific technical requirement. The goal is to remove a delivery constraint, not to increase project staffing without a clear scope.

Sustainable Capacity Comes From Better Engineering Systems

Before approving another hiring round, review the delivery environment. If releases are delayed by manual approvals, weak tests, unstable infrastructure or cross-team dependencies, those constraints should be addressed alongside recruitment.

A practical capacity plan usually combines several actions:

Remove the largest workflow bottleneck.
Clarify ownership and decision rights.
Automate repetitive testing and deployment work.
Reduce risky technical debt in frequently changed areas.
Add engineers where a genuine skills or workload gap remains.

Engineering capacity should support consistent delivery while keeping production stable, systems secure and the codebase maintainable.

Hiring helps when roles, responsibilities and delivery processes are already clear. Strong platform foundations, effective tooling and defined ownership allow teams to scale without slowing decisions or increasing dependencies between engineers.

Microsoft’s platform engineering work also highlights the role of standardised development paths in reducing operational toil and simplifying software delivery at scale.

How to Connect Your AI Agent to Live VC Fund Data Using MCP

Nica Furs — Fri, 24 Jul 2026 14:53:00 +0000

If you're building AI workflows for startup founders, fundraising research, or investor intelligence, Fund Momentum now provides an MCP server with 970+ active VC funds, live GP signals, and AI-powered startup matching.

Here's how to integrate it in 5 minutes.

Step 1 — Get your API key

curl -X POST https://fundmomentum.vc/_api/agent/register \

  -H "Content-Type: application/json" \

  -d '{"agent_name": "my-agent", "email": "you@company.com"}'

Returns:

{

  "api_key": "abc123...",

  "agent_credits": 0,

  "mcp_endpoint": "https://fundmomentum.vc/_api/mcp"

}

Step 2 — Claude Desktop

~/Library/Application Support/Claude/claude_desktop_config.json:

{

  "mcpServers": {

    "fund-momentum": {

      "url": "https://fundmomentum.vc/_api/mcp",

      "headers": { "X-API-Key": "YOUR_KEY" }

    }

  }

}

Now ask Claude: "Which pre-seed funds in Austria are actively deploying right now?"

Step 3 — Python / LangChain

import requests, json


def query_fm(tool, args, api_key):

    r = requests.post(

        "https://fundmomentum.vc/_api/mcp",

        headers={"X-API-Key": api_key, "Content-Type": "application/json"},

        json={"jsonrpc": "2.0", "method": "tools/call",

              "params": {"name": tool, "arguments": args}, "id": 1}

    )

    return r.json()["result"]



result = query_fm('match_startup', {

    "description": "B2B SaaS for legal teams, pre-seed, raising €2M, DACH",

    "stage": "pre_seed", "country": "Austria"

}, 'YOUR_KEY')

matches = json.loads(result["content"][0]["text"])

Available tools

search_funds (Starter) — Filter 970+ funds by stage/country/industry

get_fund (Starter) — Full profile, thesis, check size

get_fund_signals (Agent) — Live GP signals, deployment status

match_startup (Agent) — AI matching against your description

get_gp_profile (Agent) — Individual partner intelligence

Every response includes credit balance

{

  "_meta": {

    "credits_remaining": 9847,

    "cost_per_call": "€0.01",

    "billing": "per_call"

  }
}

Pricing: €10 for 1K credits, €80 for 10K, €500 for 100K. Credits never expire.

GitHub: schneidavie/fundmomentum

6 Outbound Prospecting Tools That Replace Guesswork With Data in 2026

Nica Furs — Wed, 22 Jul 2026 14:52:07 +0000

What Separates a Real Outbound Tool From a Glorified Spreadsheet

An outbound prospecting tool needs to do three things in sequence: identify who to contact, confirm you can actually reach them, and help you reach them systematically rather than one email at a time. Miss any one of the three, and you are back to manual work with extra steps.

Apollo.io

Apollo bundles a 275 million contact database with sequencing, intent data, and CRM sync, aiming to be the single tool an outbound team lives inside all day.

The Verdict: The sequencing depth is real and the intent layer adds genuine prioritization value. The catch is a reported 15 to 25 percent bounce rate on "verified" contacts, which means the outbound motion built on top of that data inherits some risk before it even starts.

SignalHire

SignalHire covers discovery and verification tightly, returning real-time verified emails and phone numbers from a single search across LinkedIn, GitHub, and company websites.

The Verdict: Strong on the "who" and the "can I reach them" questions. SignalHire.com does not include native sequencing, so most outbound teams pair it with a separate cadence tool, but the accuracy of what it hands off is genuinely high.

Cognism

Cognism's outbound data is built around manually verified mobile numbers across 15 European markets, checked against country-specific Do Not Call lists, with SOC 2 Type II and ISO 27001 certification behind it.

The Verdict: For outbound teams targeting the UK and EU specifically, this is close to the compliance and accuracy gold standard. For teams focused purely on North America, the specialization is wasted spend.

Seamless.AI

Seamless.AI leans into real-time web search rather than a static database, aiming to sidestep the staleness problem that eventually catches up with every large contact database.

The Verdict: Search volume and speed are genuine strengths. Accuracy consistency is the trade-off, with user reviews reporting a noticeable range between excellent and unusable results depending on the target contact's online footprint.

LeadIQ

LeadIQ captures verified contacts directly from LinkedIn and routes them straight into Salesloft, Outreach, or Salesforce, positioning itself as the connective layer rather than a standalone outbound engine.

The Verdict: For teams already committed to one of those three sequencing platforms, LeadIQ removes friction elegantly. Outside that specific stack, its standalone value is more limited.

VoilaNorbert

VoilaNorbert combines real-time search with a certainty score on every result and a pricing model that does not charge for a failed search, a small but genuinely outbound-friendly feature.

The Verdict: Simple, transparent, and low-risk to test. The database, at roughly 100 million prospects, is meaningfully smaller than the enterprise-scale competitors on this list, which limits it for large-volume outbound campaigns.

Comparison Table

A Practical Way to Test Any Outbound Tool

Pull your actual current target list, not a sample or demo dataset
Run discovery and verification through the shortlisted tool
Send a small, genuinely representative test batch, tracking hard bounces specifically
Note how much manual work remained after the tool's automation ran its course
Calculate cost per qualified conversation, not just cost per contact found

Key Takeaways

The strongest outbound tools handle discovery, verification, and sequencing as a connected chain, not isolated steps
Bundled sequencing convenience sometimes comes at the cost of verification accuracy
Regional specialization, like Cognism's European focus, can outperform general-purpose global tools for specific markets
Testing against your actual target list beats trusting any vendor's aggregate accuracy number

Quick Glossary

Discovery: Locating a contact's likely or confirmed details based on a name, company, or profile.

Verification: Confirming a discovered contact detail is currently active and reachable.

Sequencing: Automating a multi-touch outreach cadence across email and other channels.

Bounce rate: The percentage of sent emails that fail to reach an active inbox, a direct signal of data quality.

Intent data: Behavioral signals indicating a contact or company is actively researching or evaluating a solution.

What developers learn pulling company data from official business registries

Nica Furs — Tue, 21 Jul 2026 10:45:19 +0000

Open government business registers are a surprisingly useful and surprisingly awkward data source. Here is what teams wish they had known before integrating one.

Every so often a feature lands on a developer's plate that sounds trivial and turns out to be a rabbit hole. A common one: "let users verify a company by its registration number." How hard could it be? The data is public. There are official registries. Surely it is just an API call.

It is never just an API call.

Teams that have wrangled official business-registry data across a few jurisdictions tend to come out the other side with a working feature and a list of things they wish someone had told them first. This is that list. For anyone about to touch company data, open corporate registers, or "know your customer" style verification, it might save a week.

Public does not mean easy

The first surprise is that "the data is public" and "the data is accessible" are very different statements.

Most developed countries maintain an official business register. Legally the core data is public: company name, registration number, legal form, status, directors, sometimes ownership and annual filings. But how a developer actually gets at it ranges from "clean open-data API with a documented schema" to "there is a website, good luck." Some countries publish proper open datasets. Others hide everything behind a form with a session cookie and a CAPTCHA, and their idea of an API is a paginated HTML table.

So before anyone promises a feature, it is worth spending an afternoon finding out what the source actually offers for the specific countries in scope. The gap between the best and worst national registers is enormous, and it dictates the whole architecture.

Identifiers are messier than expected

A company registration number looks like it should be a nice clean primary key. Sometimes it is. Often it is not.

Formats differ per country, which is expected, but the annoying part is the near-misses. Numbers get formatted with spaces, dots, or country prefixes inconsistently. The same company can appear under a slightly different legal name in two sources. Historical names linger. A company that changed its form keeps its number but changes almost everything else about itself.

A few habits tend to save pain:

Store the raw identifier exactly as the source gives it, and a normalized version for matching. Never overwrite the original.
Normalize aggressively for comparison (strip whitespace, punctuation, casing) but display the canonical source value.
Treat the registration number plus the country as the real key. The number alone is not globally unique.

// naive normalization that catches most matching bugs function normalizeRegNo(raw) { return raw .toUpperCase() .replace(/[\s.\-\/]/g, "") // spaces, dots, dashes, slashes .replace(/^[A-Z]{2}(?=\d)/, ""); // strip a leading country prefix before digits }

That last line is deliberately conservative. Stripping prefixes is risky, because in some jurisdictions the letters are part of the number, not a country code. Which points to the real lesson.

Model the data around "this is a claim from a source at a point in time"

The mistake teams tend to make early is treating registry data as the truth. It is not. It is what a particular source reported at a particular moment. Sources lag. They disagree. They fix errors. A company can be marked active in one place and struck off in another because one updated last week and the other last quarter.

The moment a schema stops storing company.status = "active" and starts storing status = "active", source = X, retrieved_at = timestamp, everything gets easier. Conflicts become visible instead of silently overwriting each other. The system can show a user where a fact came from and how fresh it is, which turns out to be the single most trust-building thing in the whole feature. People believe "active as of yesterday, per the national register" far more than a bare green checkmark.

This is basically provenance, and for anything verification-flavored, it belongs in the design from day one. Retrofitting provenance onto a schema that assumed single-source truth is miserable.

Freshness is a product decision, not just a technical one

Company data changes: new directors, address changes, dissolutions, name changes. How stale is too stale depends entirely on what the data is used for. Displaying a company profile? Daily or weekly is probably fine. Making a decision that carries legal or financial weight? It needs to be current, and the timestamp should be visible.

The refresh strategy is worth deciding explicitly rather than letting it emerge by accident. Cache hard for read-heavy display, but keep a path to force a fresh pull when it matters. And always surface the "last updated" value to the user. Hiding it does not make the data fresher, it just makes the application silently responsible for its staleness.

Rate limits and being a good citizen

Official registers, and the aggregators that sit on top of them, are often run on modest infrastructure or with genuine per-query costs. Hammering them with unbounded requests is both rude and a good way to get blocked.

Batch and cache. Do not re-fetch a company that was looked at an hour ago.
Respect rate limits, and back off politely on errors instead of retrying in a tight loop.
For bulk data, look for an actual bulk or open-data download rather than scraping record by record. Many registers offer one, and it is almost always the right answer for analytics.

When to build versus when to borrow

Here is the honest conclusion. For a single well-served country with a good open-data API, integrating directly is very doable and worth doing. For multi-country coverage, or for jurisdictions with awkward or paywalled registers, the integration and normalization work adds up fast, and it is often cheaper to use an aggregator or a specialist that has already solved the messy parts.

This is jurisdiction-dependent in a big way. Some countries make it a joy. Estonia, for example, is unusually developer-friendly here: company data, ownership, and filings are openly available and genuinely structured, which is a large part of why so many digital businesses base themselves there. For teams working with entities in a specific country that would rather not build the plumbing themselves, providers who deal with these registers daily, like Capture, handle the formation and verification side and can be a shortcut past a lot of this. Either way, the principles above still apply to whatever the data source returns.

The takeaways

The four things worth remembering:

Check what the source actually offers before designing anything. Public does not mean accessible.
Store raw and normalized identifiers, and key on number plus country.
Model every fact as a claim with a source and a timestamp. Provenance is the feature.
Surface freshness to the user, and be a polite API citizen.

Company data looks boring from the outside and turns out to be a neat little case study in provenance, data modeling, and the gap between "public" and "usable." For anyone about to go down this road, hopefully this shortens the trip.

What official registers have developers found especially good or especially painful to work with? The war stories tend to pile up in the comments.

A Practical Framework for Building AI Products Operators Actually Adopt

Nica Furs — Mon, 20 Jul 2026 12:09:08 +0000

Developers are building faster than ever. AI tools, APIs, open-source frameworks, cloud infrastructure, and streamlined deployment now make it possible to create prototypes in days that would have taken months in previous cycles. That speed is valuable. However, in enterprise and service-business environments, a prototype is not the same as adoption.

Sam Lee’s perspective comes from operating experience rather than engineering alone. As former Chairman and CEO of Prospect Medical Holdings, he saw how technology decisions unfold in complex environments involving many stakeholders. In healthcare, a product must account for compliance, urgency, staffing, patient trust, documentation, and operational accountability. That experience now shapes how he advises and evaluates AI-enabled companies through Sam Lee Ventures.

For developers building AI products, the key lesson is simple: the user is not merely a persona. The user is part of a workflow with constraints, incentives, exceptions, escalation points, and potential failure modes. If a product does not account for these realities, implementation may stall regardless of how impressive its model or interface appears.

A practical framework begins with the job to be done. What specific work is the AI product improving? Is it routing information, answering questions, summarizing records, prioritizing tasks, qualifying leads, drafting communications, detecting anomalies, or coordinating follow-up? The more specific the workflow, the easier it becomes to design around measurable value.

The second step is mapping the handoff. AI products often fail not because the model is weak, but because the product does not define what happens next. Who receives the output? Can the user edit it? When does a human review it? What confidence threshold triggers escalation? How is the action logged? What should the system do when it does not know?

The third step is respecting data quality. Operators understand that business data is rarely perfect. Names may be inconsistent, records incomplete, fields outdated, and important context stored outside the system of record. Developers who build around idealized datasets may be surprised when production use exposes edge cases. A strong product should communicate uncertainty honestly and remain useful even when the data is messy.

The fourth step is measuring adoption, not merely usage. A team may log in because leadership requested it, but that does not necessarily mean the product is creating value. Better measures include time saved, faster response times, reduced revenue leakage, fewer manual steps, faster onboarding, clearer accountability, and fewer missed handoffs.

The fifth step is designing for both the buyer and the user. In many service businesses, the executive buyer wants productivity, consistency, visibility, and return on investment. The day-to-day user wants fewer interruptions, less duplicate work, and a tool that does not make the job more difficult. Products that serve both audiences have a stronger chance of achieving durable adoption.

This is why domain context matters. Builders do not need to become hospital executives, bankers, attorneys, or operators in every vertical. However, they need enough curiosity to understand the operating environment before presenting a solution. The strongest technical teams spend time studying the workflow, not only the codebase.

Lee’s work at Sam Lee Ventures focuses on this connection between technology and execution. The most promising AI companies will not be those that demonstrate model capability alone. They will be the companies that translate that capability into outcomes operators can trust, manage, and measure.

The opportunity for developers is significant. AI products that understand operational realities can become part of the infrastructure of modern businesses. However, adoption will favor products that are practical, explainable, integrated, secure, and measurable. In applied AI, the challenge is no longer simply building something that works. It is building something organizations can actually use.

How developers can think about payment infrastructure beyond the checkout button

Nica Furs — Fri, 17 Jul 2026 08:32:31 +0000

For most users, a payment is simple. They choose a product, click a button, approve the payment, and expect everything to work.

For developers, that button is only the front door.

Behind it sits a chain of decisions, events, checks, fallbacks, messages, statuses, and financial movements. A checkout can look clean on the surface while the infrastructure behind it is quietly carrying the real weight: authorisation, authentication, payment method availability, retries, settlement, reconciliation, refunds, chargebacks, reporting, and fraud prevention.

That is why payment infrastructure should not be treated as a final integration task at the end of a product roadmap. It is part of the product experience itself.

If the payment layer is slow, fragile, or badly designed, users do not blame the payment provider. They blame the business.

The checkout button is only the visible layer

A good payment experience often feels invisible. The customer should not need to understand what happens after they click “Pay”. But developers do.

A simplified payment flow might look like this:

The customer selects a payment method.
The frontend sends the payment request.
The backend creates or confirms a payment.
The customer may need to complete authentication.
The payment is authorised, declined, or placed in a pending state.
The system receives status updates.
The order, subscription, wallet, or account balance is updated.
The transaction is settled and later reconciled.

Each step can fail in different ways.

A card may be declined. A customer may abandon authentication. A webhook may arrive late. A bank may return a pending status. A payment method may not be available in a particular market. A refund may need to be tracked separately from the original transaction.

From a user’s point of view, these are all “payment issues”. From an engineering point of view, they are state-management problems.

Payment status is not always binary

One common mistake is treating payments as either successful or failed.

In reality, payment states can be more nuanced. A transaction can be:

Created
Pending
Requires customer action
Authorised
Captured
Failed
Cancelled
Refunded
Partially refunded
Disputed
Settled

For developers, this means the payment state should not be buried as a simple boolean like isPaid.

That may work for a very basic flow, but it becomes limiting as soon as the business adds subscriptions, partial captures, delayed fulfilment, manual reviews, refunds, chargebacks, or multiple payment methods.

A better model treats payments as lifecycle events. The order or account state should respond to payment events rather than assume that the first response from the payment API is the final truth.

A useful rule of thumb: your frontend can guide the payment experience, but your backend should own the final state.

Webhooks are not optional plumbing

Webhooks are often treated as a technical detail, but they are central to reliable payment infrastructure.

The first API response tells you what happened at that moment. A webhook tells your system what happened later.

This matters because payments are asynchronous by nature. A customer may complete authentication after being redirected. A bank may update the transaction status. A dispute may be opened days later. A refund may succeed after the original request has already returned a pending response.

A resilient webhook setup should account for:

Duplicate events
Out-of-order delivery
Delayed delivery
Failed delivery attempts
Signature verification
Idempotent processing
Internal retry logic
Event logging for audits and debugging

Idempotency is especially important. If the same webhook arrives twice, the system should not create two orders, send two invoices, or give the customer double access.

Think of webhooks like delivery drivers in a busy city. Most arrive on time, but some take a different route, some arrive late, and occasionally two drivers bring the same parcel. Your receiving process needs to handle that without causing chaos.

Failed payments are often infrastructure problems

Not every failed payment is caused by a customer having insufficient funds.

Payments can fail because of:

Poor authentication handling
Missing local payment methods
Incomplete billing details
Network or timeout issues
Weak retry logic
Poor routing decisions
Unsupported currencies
Fraud rules that are too strict
Confusing checkout UX
Payment methods that do not match customer preferences

For SaaS and ecommerce businesses, failed payments are not just technical events. They affect revenue, conversion, churn, customer support, and trust.

A developer-friendly payment setup should make it easy to understand why a payment failed and what should happen next.

For example:

Should the customer be asked to try another card?
Should the system retry automatically?
Should the subscription enter a grace period?
Should fulfilment be paused?
Should support be notified?
Should the event be shown in the admin dashboard?

The payment provider’s API response is only one part of the answer. The product logic around that response is where the customer experience is shaped.

Multi-market businesses need local payment thinking

Payment infrastructure becomes more complex when a business expands across markets.

A checkout that works well in one country may underperform in another. Customers in different regions prefer different ways to pay. Some markets are card-heavy. Others rely more on bank transfers, wallets, local payment methods, or alternative payment methods.

For developers, this creates several product and infrastructure questions:

Which payment methods should appear for each country?
Which currencies should be supported?
Should payment options be shown dynamically?
How should failed payment attempts be routed?
How should refunds work across payment methods?
How should reconciliation happen across accounts, currencies, and processors?

Hard-coding one global payment flow can become expensive later. A more flexible setup allows payment methods, currencies, and routing logic to adapt as the business grows.

This is where working with a provider such as payabl.’s payment infrastructure for digital businesses can help teams connect online payments, in-person payments, business accounts, cards, and local payment methods within a broader operational setup.

The payment layer should talk to the rest of the business

Payments do not live in isolation.

A single transaction may touch:

Checkout
Order management
Subscription billing
CRM
Accounting
Fraud monitoring
Customer support
Business intelligence
Reconciliation
Payout reporting

If payment data is difficult to access or interpret, every team downstream feels it.

Developers can reduce this pain by designing payment infrastructure with internal users in mind. That means storing useful references, making transaction states visible, logging important events, and ensuring finance teams can reconcile what happened.

For example, a transaction record should ideally connect the technical payment event with business context:

Customer ID
Order ID
Payment ID
Payment method
Currency
Amount
Status
Failure reason
Refund status
Settlement reference
Timestamp history

This makes debugging easier, but it also makes reporting and financial operations more reliable.

Card issuing and wallets add another layer

For some businesses, payment infrastructure does not stop at accepting payments.

They may also need business accounts, virtual cards, physical cards, Apple Pay provisioning, spend controls, or operational payment flows for teams and suppliers.

That creates another technical layer. Instead of only thinking about money coming in, developers also need to think about how money moves out, how cards are created, how cards are tokenised, how wallet provisioning works, and how spend is monitored.

Virtual cards, for example, can support use cases such as:

Team spending
Supplier payments
Marketing budgets
Travel expenses
Platform operations
Controlled recurring payments

When cards are provisioned into wallets such as Apple Pay, the user experience becomes even more immediate. But the infrastructure still needs to handle eligibility, tokenisation, card status, authentication, controls, and transaction monitoring.

Again, the simple user experience depends on a lot of careful backend design.

What developers should look for in payment infrastructure

When evaluating a payment setup, developers should look beyond whether the API can create a transaction.

Useful questions include:

Is the API well documented?
Are payment states clear and predictable?
Are webhooks reliable and easy to test?
Is idempotency supported?
Can the system support multiple payment methods?
Can it support multiple markets and currencies?
How are refunds, disputes, and chargebacks handled?
Is reporting detailed enough for finance teams?
Are there tools for testing edge cases?
Can the infrastructure support future products, such as cards or in-person payments?
Does the provider help reduce operational complexity as the business scales?

The best payment infrastructure is not only about accepting a payment today. It is about supporting the product, finance, risk, and customer experience needs that appear tomorrow.

Build payments like a product system, not a checkout add-on

A checkout button may look like one small part of the user journey, but it connects to some of the most important parts of a business.

Revenue, trust, fulfilment, reporting, cash flow, and customer retention all pass through the payment layer.

For developers, that means payment infrastructure deserves the same level of design thinking as authentication, database architecture, observability, or security.

A good payment system should be reliable when things go right, but also predictable when things go wrong. It should help teams understand payment states, recover from failures, support new markets, and give finance teams the data they need.

Because in the end, a payment is not just a button.

It is a business-critical workflow hiding behind one.

Best IPTV UK 2026: The 7 Best IPTV UK Providers Tested and Ranked

Nica Furs — Mon, 06 Jul 2026 15:38:59 +0000

Choosing the best IPTV UK service in 2026 is not easy. The market is full of IPTV UK providers that all claim to offer thousands of channels, real 4K and a cheap IPTV subscription, but only a handful deliver. To help you pick the best IPTV UK service with confidence, we spent weeks testing the leading IPTV providers on real devices at peak times. Here are the 7 best IPTV UK services, ranked, with exact prices and honest verdicts.

How We Ranked the Best IPTV UK Services

We did not just search for the best IPTV UK service and copy a list. We subscribed to each IPTV service and used it for at least five days, running every one during peak evening hours when server load is highest. We tested live sport, checked whether the 4K was genuine or upscaled, and measured how fast each IPTV provider replied to support. Only the seven IPTV subscriptions below passed every test, and each is the best IPTV UK option for a different type of viewer.

The 7 Best IPTV UK Services 2026

1. NUXARATV.COM: Best IPTV UK Overall

NUXARATV is the best IPTV UK service overall in 2026. With more than 55,000 live channels, it offers the largest channel catalogue of any IPTV UK provider in this comparison, plus 150,000 movies and shows in 4K, HD and SD. Anti-freeze technology keeps streams stable, all sport channels are included, and you can choose 1, 2 or 3 connections. The best IPTV UK pick for anyone who wants the widest choice.

NUXARATV features:
✔ 55,000+ live channels
✔ 150,000+ movies & shows
✔ 4K / HD / SD quality
✔ All UK sport channels included
✔ Anti-freeze technology
✔ 1, 2 or 3 connections
✔ Works on any Firestick
✔ Price: £56 / year

2. KEZELTV.COM: Best IPTV UK for Sport

KEZELTV is the best IPTV subscription for sport and on-demand content in the UK. This IPTV UK provider offers more than 30,000 channels and 190,000 movies and shows, all UK sport channels and pay-per-view included, in 4K, FHD and HD. A built-in VPN, anti-freeze, 4-day catch-up TV and EPG complete the package, with a 30-day money-back guarantee that makes it one of the lowest-risk IPTV subscriptions to try.

KEZELTV features:
✔ 30,000+ live channels
✔ 190,000+ movies & shows
✔ 4K / FHD / HD quality
✔ All UK sport channels + PPV
✔ Anti-freeze & built-in VPN
✔ Catch-up TV 4 days + EPG
✔ 30-day money-back guarantee
✔ Price: £60 / year (+1 month free)

3. OREXETV.COM: Most Trusted IPTV UK Provider

OREXETV is the most trusted IPTV UK provider, rated 4.8 out of 5 on Trustpilot, the highest score in this comparison. This best IPTV UK service includes more than 25,000 channels and 130,000 movies and shows in genuine 4K, with anti-freeze, a built-in VPN, catch-up TV and pay-per-view. Stability during live sport is the best we tested. For anyone who wants a reliable IPTV subscription above all, OREXETV is a safe bet.

OREXETV features:
✔ 25,000+ live channels
✔ 130,000+ movies & shows
✔ Trustpilot 4.8/5 (best rated)
✔ Genuine 4K / FHD / SD
✔ Anti-freeze & built-in VPN
✔ Catch-up TV + pay-per-view
✔ Best sport stability
✔ Price: £62 / year

4. TVOXAR.COM: Best IPTV UK Subscription for Content

TVOXAR is the best IPTV UK provider for maximum content. This IPTV subscription offers more than 30,000 channels and 150,000 movies and shows, including over 2,000 dedicated sport channels in 4K. A built-in VPN, anti-freeze, catch-up TV and EPG are all included, and the annual plan gives one month free. Ideal for UK sport fans and lovers of international content.

TVOXAR features:
✔ 30,000+ live channels
✔ 150,000+ movies & shows
✔ 2,000+ sport channels in 4K
✔ 4K / HD / SD quality
✔ Anti-freeze & built-in VPN
✔ Catch-up TV + EPG
✔ 1 month free (annual plan)
✔ Price: £63 / year

5. NEXOMIR.COM: Best Value IPTV UK Subscription

NEXOMIR offers the best value of the IPTV UK providers we tested. This IPTV subscription combines more than 30,000 channels and 150,000 movies and shows in 4K, at one of the lowest prices. Anti-freeze held firm through every test, and support replied in under ten minutes. A cheap IPTV subscription with no compromise on the catalogue.

NEXOMIR features:
✔ 30,000+ live channels
✔ 150,000+ movies & shows
✔ Genuine 4K / FHD / SD
✔ Best value annual plan
✔ Anti-freeze & built-in VPN
✔ Support under 10 minutes
✔ Fast channel switching
✔ Price: £55 / year

6. VISSOLOTV.COM Biggest VOD Library

VISSOLOTV has the biggest on-demand library of any IPTV UK service in this comparison, with close to 198,000 movies and shows. If you watch more box sets than live TV, this is the IPTV UK provider to choose. This IPTV subscription also includes more than 25,000 channels, anti-freeze, stable servers and a 7-day money-back guarantee. A great choice for households that stream mostly on demand.

VISSOLOTV features:
✔ 25,000+ live channels
✔ 198,000+ movies & shows (biggest VOD)
✔ 4K / FHD / HD / SD quality
✔ Anti-freeze technology
✔ Stable servers
✔ 7-day money-back guarantee
✔ Great for films & box sets
✔ Price: £68 / year

7. TVZITAM.COM Cheapest IPTV UK Subscription

TVZITAM is the cheapest IPTV subscription and the most flexible in the UK. It is the only IPTV UK provider here to offer a monthly plan, ideal for an extended free IPTV trial. Its annual price is the lowest in this comparison. This IPTV subscription includes more than 15,000 channels, 60,000 movies and shows, 99.9% guaranteed uptime and 24/7 support. Fully M3U and Xtream Codes compatible, it works on any IPTV box or Android TV box.

TVZITAM features:
✔ 15,000+ live channels
✔ 60,000+ movies & shows
✔ Monthly plan available
✔ Cheapest IPTV subscription
✔ 99.9% guaranteed uptime
✔ 24/7 live chat support
✔ M3U & Xtream Codes compatible
✔ Price: £53 / year

What Makes the Best IPTV UK Service

Server stability at peak times is the most important factor when choosing the best IPTV UK service. An IPTV UK provider whose streams drop during a live event is not a serious option, whatever the price. Genuine 4K, fast setup, responsive support and a clear guarantee also matter. Always use a free IPTV trial before buying an annual IPTV subscription, ideally in the evening. Be wary of any cheap IPTV subscription under £3 a month, as the best IPTV UK service usually costs £5 to £7 a month on an annual plan.

How to Set Up Your IPTV Subscription on a Firestick

After you buy IPTV, you receive your login details by email within minutes. For a Firestick, search for IPTV Smarters Pro or TiviMate in the Amazon app store and install it. On Android TV, use the Google Play Store, and on iPhone or iPad, download GSE Smart IPTV. Enter your details and all your channels load within seconds. For the best experience, use an ethernet connection rather than wifi, especially for 4K and live sport.

Is IPTV Legal in the UK?

IPTV technology is completely legal in the UK. The legal status of a service depends on whether the IPTV UK provider holds the correct broadcasting rights. The signs of a serious IPTV subscription are secure payment, transparent terms, a refund policy and responsive support. All seven IPTV providers here offer a free IPTV trial before you buy.

Frequently Asked Questions

Which is the best IPTV UK service in 2026?
NUXARATV is the best IPTV UK service overall with 55,000 channels, KEZELTV is the best IPTV subscription for sport, and OREXETV is the most trusted IPTV UK provider (Trustpilot 4.8/5).

What is the cheapest IPTV UK subscription?
TVZITAM is the cheapest IPTV subscription at £53 a year, followed by NEXOMIR at £55 and NUXARATV at £56. All offer a free IPTV trial.

How much does an IPTV subscription cost in the UK?
A quality IPTV subscription costs between £53 and £68 a year, roughly £4.40 to £5.70 a month.

Does IPTV work on a Firestick?
Yes. Every IPTV UK service here works on the Amazon Firestick via apps like IPTV Smarters Pro and TiviMate, the most popular way to watch IPTV in the UK.

How do I get a free IPTV trial?
All seven IPTV UK providers here offer a free IPTV trial. Use it in the evening on a live sport stream to judge the best IPTV UK service under peak load.

Final Verdict

After our tests, NUXARATV is the best IPTV UK service in 2026 thanks to its 55,000 channels, followed by KEZELTV for sport. OREXETV remains the most trusted IPTV UK provider, while TVZITAM and NEXOMIR offer the cheapest IPTV subscription. Whatever you choose, use a free IPTV trial before you buy IPTV, and pick the IPTV UK provider that best matches your needs.

Agentic AI Won't Fix Your Automation Problems on Its Own (Here's What Actually Will)

Nica Furs — Thu, 02 Jul 2026 10:12:20 +0000

If you have spent any time in enterprise IT over the last year, you have probably noticed that "agentic AI" has become one of those terms that shows up in every roadmap conversation, whether or not anyone in the room agrees on what it actually means. Some teams are picturing fully autonomous systems that run entire workflows without human input. Others are just trying to get a chatbot to stop hallucinating ticket statuses. Both of those things technically fall under the agentic AI umbrella, which is part of the problem.

For developers and platform engineers who are actually responsible for building this stuff, the interesting question isn't whether agentic AI is real or hype. It clearly exists, and it clearly works in specific, well-scoped use cases. The harder question is what has to be true about your systems before an AI agent can act autonomously without creating more cleanup work than it saves.

The Uncomfortable Truth About Agent Failures

Most agentic automation projects don't fail because the underlying model is bad. They fail because the agent gets dropped into an environment that was never designed to support autonomous decision-making in the first place: fragmented data sources, undocumented business logic buried in legacy systems, and no consistent way to trace what an agent actually did after the fact.

That last point matters more than most teams initially expect. When an agent executes a multi-step workflow autonomously, whether that's provisioning a new employee's accounts, triaging a support ticket, or updating a system of record, someone eventually has to answer for what happened when it goes wrong. If there's no audit trail connecting the agent's decision back to the data it used and the systems it touched, you don't have automation. You have a black box with API access, and that is a much scarier thing to explain to a compliance team.

Governance Isn't a Bolt-On, It's the Foundation

This is where a lot of teams get the sequencing backwards. The instinct is often to bolt an agent onto existing infrastructure and figure out governance later, once something breaks. In practice, the integration and data layer has to come first. An agent is only as reliable as the data it's reasoning over, and if that data lives in five disconnected systems with no shared source of truth, the agent is going to make confident, well-formatted, and occasionally wrong decisions.

This is a big part of why agentic automation is increasingly being framed as a layered architecture problem rather than a single tool decision. A workable approach generally involves three distinct layers: an integration layer that unifies data across systems into something resembling a single source of truth, an agent layer that operates on top of that unified data with defined permissions and guardrails, and an observability layer that logs what agents actually did, not just what they were asked to do. Skip the first layer, and everything built on top of it inherits the same data quality and access problems that made automation hard in the first place.

Where This Actually Pays Off in Practice

None of this means agentic automation needs to be reserved for massive, multi-year platform overhauls. Some of the most successful early deployments are narrow and boring on purpose: an agent that classifies incoming support tickets and routes them to the right queue, one that handles new employee account provisioning across a handful of systems, or one that keeps a knowledge base current by pulling from documents and databases that used to require someone to check manually. These use cases work well precisely because the scope is tight enough to reason about, test, and monitor without needing to solve enterprise-wide data governance on day one.

The pattern worth paying attention to is starting with a contained, well-instrumented use case, proving that the agent's decisions are explainable and auditable at that scale, and only then expanding the scope. Teams that try to jump straight to broad, cross-system autonomy tend to run into the same wall: the agent works fine in the demo and then falls apart the first time it hits an edge case that the underlying data never accounted for.

The Real Takeaway for Engineering Teams

Agentic AI is a genuinely useful capability, but it is not a substitute for solid integration architecture, and treating it as one is how most of these projects end up stalling. If you're evaluating agentic automation for your own stack, the questions worth asking upfront are less about which model to use and more about whether your data layer can actually support an agent making decisions against it, and whether you'll be able to explain exactly what that agent did six months from now when someone asks.

That framing shift, from "which AI tool should we buy" to "is our data and integration layer ready for autonomous decision-making," tends to separate the automation projects that scale from the ones that quietly get shelved after the pilot.

Restaurant AI is having its platform lock-in moment

Nica Furs — Thu, 11 Jun 2026 20:42:05 +0000

If you build software, you already know how to evaluate a restaurant AI tool. You just have to apply the same instincts you'd use for any dependency. What does it integrate with? What happens if the company behind it gets acquired? And is the "AI" actually doing work, or is it automation wearing a nicer label?

That framing matters more in 2026 than it did last year, because the platform layer under restaurant technology is consolidating fast.

A consolidation moment, in plain terms

In 2025, DoorDash completed a roughly $1.2 billion acquisition of SevenRooms, a guest-data and reservations platform. Around the same time, Olo — the digital ordering platform behind around 750 restaurant brands — agreed to be taken private by Thoma Bravo, a software investment firm, in a deal worth about $2 billion. So two products that plenty of operators evaluated as independent vendors now answer to new owners: one inside a delivery company, the other under private equity.

That isn't an argument against the tools. Olo and SevenRooms are still capable software with real customers. It's a dependency observation. The same way you'd think twice before building on an API owned by a competitor, restaurant operators now have to factor ownership into a multi-year contract decision.

Where the AI is actually earning its keep

Strip away the marketing and the AI that pays for itself tends to do one specific, hard-to-fake thing: it predicts or generates something a human can't easily compute by hand.

Scheduling is the clearest case. Tools like 7shifts pull historical point-of-sale data and forecast demand by daypart, then build shift plans against a labour-cost target. 7shifts runs a free plan for up to 15 staff, so the payback is easy to test before committing budget.

Voice AI is the most visible live deployment. Slang.ai answers inbound restaurant calls with a 24/7 voice agent — reservations, hours, FAQs, routing. Operators report 50 percent more phone reservations captured, calls that used to die in voicemail, plus more than 200 staff hours a month freed from the phone. That's a clean, measurable win: capture rate times average cover value, minus the subscription.

Food waste is the underrated one. Winnow puts computer vision in the kitchen to identify and weigh waste at the bin, with a documented average around $50,000 a year in savings per kitchen. For most mid-size sites, that pays back inside the first year.

Read it like any other dependency

Here's the part procurement usually gets wrong: it starts and ends at the point-of-sale system. The POS is the backbone, fine. But the AI layer with the best return in 2026 sits next to the POS, not inside it.

Scheduling, voice, food waste, and commission-free direct ordering each solve a separate problem, and none of them requires ripping out your POS. They integrate with Toast, Square, or Lightspeed as added layers, usually through the POS's existing API surface, so adding one is closer to config than to a migration. So the real evaluation question is the integration surface and the lock-in, not "which all-in-one suite do I buy."

Pricing is a useful tell here too. Owner.com publishes flat-rate pricing designed to avoid the 25 to 40 percent per-order commissions delivery platforms charge on direct orders. Public pricing usually signals genuine fit for an independent operator. A tool that hides its price behind a sales call has often priced itself out of that market already.

What a focused-tools shortlist looks like

Look across the categories and the same pattern shows up: the durable tools are the focused ones, not the broadest platforms. 7shifts does scheduling. Slang.ai answers the phone. Winnow tracks waste. Owner.com kills delivery commissions.

Each one solves a single expensive problem with a number attached, which is exactly why each survives scrutiny that the do-everything suites don't.

That lines up with a 30-tool restaurant AI evaluation from BestAIFor.com, which scored a longlist on pricing transparency, documented customer evidence, real AI capability depth, and integration breadth before ranking the strongest 15. The focused players land near the top, not because they're the biggest, but because their value is the easiest to verify.

The consolidation won't stop here. DoorDash's move into reservations and private equity's appetite for ordering platforms are a preview of the competition coming for the restaurant software layer, and the European delivery groups are positioned to play the same game. Operators — and the developers building for them — who pick focused tools with clean integrations now are the ones who keep their options open when the platform layer closes in.

The Organisations That Ignore Disinformation Risk Are Writing Blank Cheques to Their Adversaries

Nica Furs — Mon, 01 Jun 2026 11:20:14 +0000

Most organisations discover they have a disinformation problem the same way most people discover they have a structural problem with their house. By the time the damage is visible, the underlying deterioration has been underway for considerably longer than anyone would find comfortable to acknowledge.

This analogy is not rhetorical. The operational signature of a well-constructed influence operation is, by design, indistinguishable from organic reputational pressure until it has achieved sufficient scale to become self-sustaining. At that point, the causal architecture, who initiated it, through what infrastructure, toward what specific objective, has been deliberately obscured. What remains visible is the effect, a narrative that has embedded itself in the discourse surrounding an organisation, a person, or an institution, and that continues to propagate through the information environment largely independent of the original actor.

Responding to that effect without understanding its cause is not crisis management. It is crisis theatre.

The Comfortable Misdiagnosis

There is a version of this problem that is easy to sell to boards and comfortable for leadership teams to accept. In that version, disinformation is essentially a supercharged PR challenge, requiring faster monitoring, sharper messaging, and more agile communications infrastructure. The solution set is familiar, social listening tools, rapid response protocols, media relations, legal letters to the most egregious offenders. It fits within existing organisational structures. It does not require building new capability or acknowledging new categories of vulnerability.

It is also largely inadequate for the threat it claims to address.

The conflation of disinformation response with communications management reflects a fundamental misapprehension of what disinformation operations actually are. They are not, at their core, communications phenomena. They are adversarial operations, planned, resourced, and executed with specific objectives, using the information environment as the operational terrain. Treating them as communications problems applies the wrong analytical framework, generates the wrong intelligence picture, and produces responses calibrated to a threat that does not correspond to the one actually present.

The distinction matters because the response architecture for an adversarial operation is categorically different from the response architecture for a reputational crisis. One requires intelligence methodology. The other requires communications expertise. Organisations that deploy only the latter against the former are not managing the risk. They are performing the management of it.

What the Threat Environment Actually Looks Like

The academic and practitioner literature on influence operations has advanced considerably in the past decade. The work coming out of institutions including the Stanford Internet Observatory, the Oxford Internet Institute, and the EU DisinfoLab has produced a detailed empirical picture of how coordinated inauthentic behaviour is structured, resourced, and deployed across different geopolitical and commercial contexts.

Several features of this picture are worth holding in focus. First, the barrier to entry for a credible influence operation has fallen dramatically and continues to fall. Generative AI has reduced the production cost of synthetic content, credible personas, and scaled narrative seeding to a fraction of what it required even three years ago. Second, the platforms through which disinformation circulates have not developed countermeasures at a pace that tracks the evolution of the threat. Enforcement remains inconsistent, attribution tools available to non-state actors remain limited, and the incentive structures of major platforms continue to reward engagement over accuracy. Third, and most consequentially for organisations assessing their own exposure, the targeting logic of influence operations has become significantly more granular. Operations are increasingly designed not to shift mass public opinion but to influence specific, high-leverage audiences, investors, regulators, journalists, senior employees, whose decisions are consequential to the target organisation's functioning.

This last development renders audience-scale metrics largely irrelevant as a measure of operational impact. An influence operation that reaches ten million people and shifts none of their behaviour has achieved nothing. One that reaches three hundred analysts, fund managers, or regulatory officials and introduces meaningful uncertainty into their assessments of a target organisation has achieved a great deal. The sophistication with which targeting has evolved is not matched by the sophistication with which most organisations assess their own vulnerability to it.

The Operational Logic of Serious Response

The Disinformation Commission is built on a practitioner model that takes this threat environment seriously on its own terms rather than translating it into the more comfortable language of communications management. The analytical starting point is the threat actor and the operational architecture, not the content of the narrative being seeded. Source attribution, network topology, amplification infrastructure, timing patterns and the identification of target audiences are the primary analytical objects. The communicative response, if one is warranted, follows from that picture rather than preceding it.

This sequencing is not procedural fastidiousness. It reflects a genuine insight about how influence operations are structured and what effective intervention requires. An organisation that responds to a disinformation operation without first establishing who is behind it, what their operational objective is, and what their likely next move is, is navigating without a map. It may accidentally counter the operation. It may, with equal probability, accelerate it.

Persistent environmental monitoring, the maintenance of an ongoing analytical picture of the information terrain surrounding an organisation, is the prerequisite for everything else. It is also the capability that is most consistently absent in organisations that consider themselves prepared for reputational risk. The gap between having a crisis communications plan and having the intelligence infrastructure to know when and whether that plan should be activated is where most institutional responses fail.

The Reckoning That Is Already Underway

The organisations that have experienced significant disinformation operations at first hand are not, in aggregate, returning to their previous posture. The experience of navigating a coordinated false narrative through conventional communications infrastructure, watching it propagate faster than the rebuttal, seeing it embed itself in the assessments of key stakeholders despite being demonstrably false, is clarifying in a way that threat briefings rarely are.

The lesson those organisations are drawing is consistent. The capability required to manage this threat effectively cannot be assembled after the operation begins. The monitoring infrastructure, the analytical relationships, the legal pathways, the response protocols, all of it must exist before the need for it becomes acute. Organisations that are building this capability now are not being paranoid. They are being accurate about the environment they are operating in.

The information environment is not going to become more benign. The tools available to actors who wish to use it as operational terrain are not going to become less accessible. The question for any organisation that operates in a contested information space, which is to say, any organisation of any significance, is not whether this risk is real. That question has been answered, repeatedly and expensively, by the organisations that asked it too late.

The question is whether the infrastructure to manage it exists before it becomes necessary to use it.

Navigating the Future of Workers’ Comp Pharmacy Care

Nica Furs — Tue, 02 Sep 2025 17:06:42 +0000

The landscape of workers’ compensation is shifting rapidly, with pharmacy benefits management (PBM) at the center of many conversations. For employers, claims professionals, and injured workers alike, keeping track of new regulations, cost trends, and treatment options is critical.

One of the biggest challenges lies in managing prescription medications effectively. Rising drug costs, complex formularies, and the ongoing opioid epidemic have reshaped the way organizations think about pharmacy oversight. Proactive monitoring, smarter data, and transparent reporting are no longer optional—they’re essential.

Why Staying Current Matters

For organizations handling workers’ comp claims, pharmacy utilization directly impacts both recovery timelines and overall costs. Outdated prescribing patterns or a lack of oversight can lead to delayed return-to-work outcomes, unnecessary expenses, or in some cases, risks to patient safety.

That’s why resources that track evolving drug trends, guideline changes, and cost-management strategies have become invaluable. Access to real-time analysis can help claims professionals anticipate challenges and intervene before they escalate.

Leveraging Expert Insights

Forward-thinking PBMs provide not just medication management but also strategic insights into how the marketplace is evolving. With workers' comp pharmacy updates, stakeholders gain clarity on what’s driving changes—from regulatory shifts to emerging therapies—and can adjust policies accordingly.

Such updates often include:

New information on FDA approvals relevant to workplace injuries.
Guidance on managing controlled substances.
Forecasts on drug cost fluctuations.
Strategies for optimizing outcomes while minimizing risk.

The Human Impact

At its core, the purpose of staying informed is to ensure better outcomes for injured workers. A clear, timely, and evidence-based pharmacy strategy helps speed recovery and supports return-to-work goals—while also safeguarding long-term well-being.

Looking Ahead

As pharmacy costs continue to evolve, organizations that invest in proactive solutions will be better positioned to adapt. Staying ahead of these changes means more than just cost savings—it means creating a system that prioritizes both financial sustainability and compassionate care for injured employees.