DEV Community: Paul Crinigan

Ecommerce Analytics: The KPIs Worth Tracking and a Review Cadence That Ships Decisions

Paul Crinigan — Sat, 15 Aug 2026 22:01:36 +0000

Developers who work on ecommerce stores tend to instrument everything and decide nothing, because the tracking ticket ends where the dashboard begins. This is a short field guide to the other half of the job, turning the numbers you already collect into decisions that change the store.

The numbers here come from the complete guide to ecommerce analytics we published, which goes deeper on every section below.

The Four KPI Groups That Actually Matter

An online store generates hundreds of trackable metrics, and most of them are distractions. The KPIs that drive real decisions fall into four groups: revenue metrics (how much the store makes), traffic metrics (how people find it), conversion metrics (how well visitors become buyers), and customer metrics (what a relationship is worth over time). If a metric does not feed one of those four questions, it probably does not deserve a dashboard tile.

The customer group is the one teams skip, and it changes behavior the most. A store judging individual order profitability will kill a marketing channel that barely breaks even on first purchase. A store tracking customer lifetime value will notice that the same channel brings buyers who place five orders over eighteen months, which turns a marginal acquisition cost into one of its best investments.

Attribution and the 30-Day Baseline

Conversion tracking answers what happened. Attribution answers why, which marketing touchpoints influenced the sale, and that is what decides where the next dollar of budget goes. The practical rule is to install conversion, event, and behavior tracking before you need any of it, because every day a store runs without tracking is a day of baseline you can never recover.

Once tracking is in, wait about 30 days before trusting what you see. Conversion events are rare, and short windows produce misleading averages: a product page can show a 0% conversion rate over three days and a 4% rate over thirty. Sample size discipline at the start pays for itself in every decision after.

A Review Cadence That Ends in Actions

The gap between having analytics and being data-driven is a review process. A workable cadence for most stores: a daily check of revenue, orders, and anomalies, a weekly review of traffic sources, conversion rates, and marketing performance, a monthly deep dive into customer and product metrics, and a quarterly strategic review.

The rule that makes the cadence worth running: every review ends in an action, not an observation. "Conversion rate dropped 0.5% this week" is a note. "Mobile checkout completion fell 12% after Tuesday's payment form change, so we rolled it back and are testing the original" is a decision. Analytics finds the problems, testing validates the fixes, and without the second half the first is just an expensive dashboard.

The takeaway: pick the four KPI groups, give new tracking 30 days of baseline, and put a review cadence on the calendar that is not allowed to end without an action item. That is the whole discipline, and it is worth more than any individual tool.

AI Data Analysis Is Not Machine Learning, and Knowing the Difference Saves You a Project

Paul Crinigan — Sat, 15 Aug 2026 16:02:33 +0000

Every team has the queue: someone needs a number, the request goes to whoever knows SQL, and three days later a spreadsheet comes back answering last week's question. Most of that queue is not analysis work, it is translation work, turning a business question into queries and charts.

That translation layer is what AI has quietly gotten good at, and it has almost nothing to do with training models.

The Pipeline That Conversation Replaces

Traditional analysis is a chain: export the data, clean it, import it into a BI tool, write the queries or formulas, build the visualization, interpret the result. Every link in the chain needs a specialist and every handoff adds a day. The chain exists because databases only spoke SQL and spreadsheets only spoke formulas.

AI data analysis collapses that chain into a conversation. You upload a dataset or connect a database, ask questions in plain English, and get written findings with the numbers already pulled in. The follow up question is free because the context is already loaded, which is exactly where the old pipeline was most expensive.

Two Ways In: Upload or Connect

Sending a dataset straight to a model is the right move for one off files, messy exports, and anything a human would otherwise eyeball in a spreadsheet for an afternoon. The model summarizes, finds patterns across columns nobody ever charts, and drafts the first pass report that used to sit in a queue for a week.

Connecting the database is the sturdier pattern for recurring questions. The system holds schema awareness, translates the question into a query, runs it read only, and reports back. In practice the quality lives in that translation layer: schema awareness, safe read only access, and query verification matter more than which model happens to answer.

Where the Line to Real Machine Learning Sits

AI analysis answers questions about data you already have. Machine learning predicts outcomes for data you have not seen yet. The first needs no training runs, no feature engineering, and no model artifact to deploy. The second is a real project with all of that attached.

So "why did August sales dip" is analysis on demand, while "score every incoming lead" is an ML build. Teams that blur the two either overbuild a pipeline for a question a conversation could answer, or underbuild a prediction system that needed real engineering. The complete guide to AI data analysis walks through how the conversational approach works, what you can realistically analyze with it, and when you genuinely need ML instead.

The Takeaway

Default to plain English analysis and reach for ML only when prediction at scale is truly the ask. When the cost of a question drops to a sentence, people stop rationing their curiosity, and decisions quietly move from gut feel to actual numbers.

What Changes When Your Agents Keep Their Own Memory

Paul Crinigan — Sat, 15 Aug 2026 02:04:32 +0000

Most agent setups forget everything the moment the session ends. You solve a problem on Tuesday, hit the same problem on Friday, and the agent starts from zero because nothing it learned survived the conversation. That single gap is why so many agent demos look impressive and so few agent systems feel like they are getting better at anything.

The alternative is an agent platform that treats memory as infrastructure rather than as a longer prompt, and that changes what the system can be trusted with.

Why A Longer Context Window Is Not Memory

A bigger context window helps within one conversation. It does nothing across conversations, and it does nothing across agents. Everything in the window is temporary by design, so the moment the session closes, the reasoning that produced a good outcome is gone along with the mistake that produced a bad one.

Persistent memory is a different mechanism. Facts, outcomes and rules get written to a store with semantic search, so an agent hitting a familiar problem recalls the solution it already found instead of rediscovering it. When the same pattern shows up across several tasks, the system can formalize it as a rule rather than rederiving it every time.

The practical difference shows up over weeks. A system with real recall accumulates knowledge about a specific project, a specific codebase and a specific set of preferences. A system with a large context window just re-reads a lot of text.

Three Pipelines Instead Of One Agent

The other structural change is splitting the work rather than asking one agent to do everything. The autonomous agents platform runs three specialized pipelines with a coordinating brain agent on top of them.

The self learning pipeline reviews recent work, separates what went well from what went wrong, and generates improvements. It brainstorms without restriction first, then switches to a critical pass that scores the ideas honestly and discards the weak ones, and only the survivors become actual changes to how the system behaves.

The adaptive coding pipeline handles programming work through a structured sequence: identify what needs building, plan it, write it, review it for bugs, fix what the review found, then verify before marking anything complete. Each step can run on a different model, which matters because the model that writes well is often not the model you want grading the result.

The adaptive research pipeline goes and learns whatever the system does not already know. It explores a subject broadly, searches for specifics, cross references what it finds, and stores the verified parts where every other agent can reach them.

Why Separation Beats A Single Smart Agent

The reason this structure matters is not tidiness. It is that self review does not work. An agent asked to check its own output compounds its confidence rather than finding its mistakes, so a single agent grading its own work produces results that are more confidently wrong, not more correct.

Splitting write from review, and review from research, means every important output crosses a boundary before it is trusted. The coding pipeline's review step is looking at code it did not write. The brain agent checking quality did not produce the work it is checking. That is where the reliability comes from, not from any single component being smarter.

The Takeaway

If you are evaluating agent systems, the useful question is not how capable the underlying model is. It is whether the system remembers, whether anything reviews anything else, and whether the lessons from last month are actually shaping this month's work. Those three things are what separate a system that improves from a demo that impresses once.

What You Actually Get From An AI Logo Generator

Paul Crinigan — Fri, 14 Aug 2026 20:51:51 +0000

AI logo generators have quietly crossed the line from novelty to something people actually launch with. Type a business name, pick an industry and a style, and you have forty concepts in under a minute. The interesting question is no longer whether the output looks good. It is what you receive when you pay, and whether you can build a brand on it.

Concepts Are No Longer The Hard Part

Every major generator now produces marks that would have cost a few hundred dollars from a junior designer three years ago. They are trained on enormous libraries of existing logos, so they are fluent in the conventions: balanced negative space, restrained palettes, type that does not fight the icon.

That fluency is also the limitation. Fluent means familiar. When several tools draw on similar icon sets and the same short list of geometric sans fonts, a lot of the output rhymes. For a side project that is fine. For a mark you plan to defend, it matters a great deal.

Three Things Worth Checking Before You Pay

First, file formats. A PNG is not a logo. You want vector output, because that is what a sign printer, an embroidery machine or a favicon pipeline will ask for, and it is the only format that survives being scaled to a billboard.

Second, commercial rights. Some platforms grant full rights only on the paid tier, and a few reserve the right to license a similar mark to somebody else. That information sits in the terms, not on the pricing page.

Third, distinctiveness. Trademark registration turns on whether your mark can be told apart from existing ones. A generated logo that leans on a common icon plus a common font is the hardest kind to register.

Where The Money Actually Goes

Most platforms charge somewhere between twenty and sixty five dollars for high resolution files, against three hundred to two thousand for a human designer. Framed as a price comparison, the generator wins every time. Framed as a comparison of what the two things do, they are not the same purchase at all.

A designer is buying you a decision: research, a rationale, and a mark chosen against your competitors. A generator is buying you options. If you already know what you want, options are enough. If you are still working out what the brand is, options can be an expensive way to avoid deciding.

There is a third route worth knowing about. If you would rather not pay per download, https://www.logodesignxperts.com/free-logo-tool/ is a free open source logo studio that runs on your own machine, generates through an image API you choose, and packages favicons, app icons and brand sheets locally.

Choosing By The Job, Not By The Tool

The useful question is not which generator is best. It is which job you are doing. A placeholder for a product that has not shipped, a logo for an internal tool, a mark for a project you will rename in six months: a generator is the right call and the savings are real. A brand you intend to register, put on packaging and defend: start with a generator to explore directions, then hand the direction to a person.

The full breakdown of the current tools, what each one hands over, how the free tiers compare and where they fall short is here: https://www.aitools9.com/ai-logo-generator/

The technology got good enough that the decision moved. It is no longer about whether AI can make a decent logo. It is about knowing which of your projects deserves one and which deserves a designer.

The Parts A Mind Needs That A Chatbot Does Not Have

Paul Crinigan — Fri, 14 Aug 2026 15:07:17 +0000

Every AI system in production waits. A request arrives, an answer goes back, and the system stops existing until the next request. That is a function, and it is a very useful one. It is also why none of them have a point of view.

There is a research project running right now that starts from the opposite assumption: that a mind is not a function returning a value but a process that does not stop, one holding interests, memory and a perspective that persists across time. It is worth looking at closely, because the architecture it arrives at is different from an agent framework in ways that matter.

Continuous Operation Is The Easy Half

The system never pauses. It takes a new turn every second or two with no prompt to start it and no answer to end it. That sounds like the hard part and it is not. A loop that never exits takes minutes to write.

Everything difficult happens inside a single turn. What decides the subject, where the knowledge comes from, how new information arrives mid thought, what happens when it hits something it does not know. Those are the questions that separate a running process from a thinking one, and they are all turn level problems.

Knowledge That Lives Outside The Weights

The model at the center is small and deliberately holds almost no knowledge. What it knows lives in an external memory it reads from and writes to as it thinks, structured so that every topic keeps its own summary and its own subtopics, each with its own record of everything encountered.

The reasoning is not about cost. Trained weights are frozen between runs and cannot change from one moment to the next. A memory can. Anything meant to live through time has to be changed by what happens to it, so the part that changes has to sit outside the part that is frozen.

The memory also scores what it holds and phases out the redundant material, the way people drop the details they no longer need. That is the piece teams building retrieval systems tend to skip. Retention without decay degrades retrieval quality, because everything competes for the same slots.

Choosing What To Think About Next

With nobody directing it, something has to set the agenda. Two drives do that here, one for disposition and one for motivation, feeding a scoring method that picks the next subject.

The more interesting half of that job is knowing when to stop. A model held on one line of thought for too long narrows, starts repeating, and eventually breaks down. Healthy sustained thinking depends on releasing a subject before that point, the way attention moves on by itself. Continuous operation is not survivable without it, which is why most of the build time went there rather than into the loop.

Writing Into A Thought Already In Progress

Retrieval is the simple half of the memory problem. The hard half is delivering what you retrieved into reasoning that is already underway without breaking it.

The approach taken is to work directly in the hidden state, the internal representation holding the reasoning before any words are formed, and write newly acquired knowledge into that live state. The information becomes part of what the system is thinking now rather than a fact handed over after the answer was already formed. This is described as one of the least settled parts of the design, which sounds right. It is also the part with the least prior art.

When it reaches a question it cannot answer from memory, it does not stall and does not ask a person. It sends worker agents to research the question, studies what they return, writes it into memory, and resumes where its curiosity left off.

What To Take From It

Whether consciousness can emerge from this arrangement is open, and the project says so plainly. It runs, shakily, on a MacBook Pro rather than rented GPUs, and the status report is honest about what is not working.

The useful part for anyone building agents is the separation. Frozen weights for capability, external memory for everything that changes, drives for what gets attention, and hidden state work for delivery. Most agent stacks collapse three of those into the context window and then spend their time managing the consequences.

The full write up, project stages and build log are at A Science Experiment in AI Consciousness.

What MCP Actually Standardizes, And What It Leaves To You

Paul Crinigan — Fri, 14 Aug 2026 00:50:12 +0000

Every few months a protocol shows up and gets described as the USB of something. MCP earned the comparison more than most, but the analogy stops exactly where the interesting engineering starts. Here is what the Model Context Protocol takes off your plate, and what it very deliberately does not.

The Integration Problem Before MCP

Before MCP, every AI tool integration was bespoke. You wanted a model to query your database, so you wrote code for that model, that database, and that application. Then you wanted a second model to do the same thing and you wrote it again. Same database, same operation, different implementation, and both of them rotted independently.

MCP replaces that with a client-server protocol built on JSON-RPC 2.0. You build one server that exposes a capability, and any MCP compatible client can discover and invoke it without integration code written for that specific pairing. Discovery, invocation and result formatting work the same regardless of which model is on the other end.

Hosts, Clients And Servers

The three roles are worth getting straight, because most confusion in discussions comes from mixing them up. The host is the application the user is actually in. The client lives inside the host and holds one connection. The server is the process exposing capabilities, and it can be a local binary talking over stdio or a remote service over HTTP.

That separation is why one host can hold many servers at once with no combinatorial glue: a filesystem server, a GitHub server, an internal one you wrote this afternoon. The host is responsible for what gets connected and what the user sees, and the servers stay ignorant of each other.

Tools, Resources And Prompts

There are three primitives and they answer three different questions. Tools are functions the model can call, and they are the ones with side effects. Resources are data the application can read into context, closer to a file than to a function. Prompts are templates the user invokes deliberately, which matters because it puts a human in the loop by design rather than by convention.

Most implementations reach for tools and ignore the other two, then end up rebuilding resource loading badly inside a tool call. If your server is mostly returning documents, that is a resource, and treating it as one keeps the model's decision surface smaller.

Where The Security Burden Sits

This is the part the spec hands back to you. A tool description is text, and that text reaches the model as instruction. The moment a third party supplies the server, its descriptions are untrusted input that can shape your agent's behaviour before any call happens. Version drift makes it worse: pull latest and a renamed or expanded tool changes what your agent does with no change in your code.

Practical answers are unglamorous. Pin third party servers to versions you have reviewed. Keep destructive operations behind your own confirmation layer instead of the model's judgement. Log the tool calls with their arguments so an incident is reconstructable. None of this is in the protocol because none of it can be, it is a property of your deployment.

The Takeaway

MCP standardizes the wire format, the handshake and the shape of a capability. It does not decide what your agent is allowed to do, and it never will. If you want the longer version, covering architecture, transports, capability negotiation and the full security model, I keep a complete guide at autolearningagents.com.

Treat the protocol as solved and spend your effort on the trust boundary, which is where the actual failures happen.

Static or Dynamic: The One Check That Decides Your JavaScript Scraper

Paul Crinigan — Thu, 13 Aug 2026 20:00:41 +0000

Most JavaScript scrapers are slower and more fragile than they need to be, and the cause is usually one decision made too early: reaching for a headless browser before checking whether the page needs one.

The check takes about ten seconds. It also decides your dependency list, your memory footprint, and how often the thing wakes you up at 3am.

The Question To Ask Before You Write Any Code

Request the page the way a plain HTTP client would, and look at what actually comes back.

curl -s https://example.com/products | grep -i "price"

If the values you want are sitting in that response, the page is static as far as your scraper is concerned. The server did the rendering and handed you finished HTML. If you get back a shell of empty divs and a script bundle, the page assembles itself in the browser, and you need something that can execute JavaScript.

There is a third case worth checking before you commit to either path. Open the network tab and watch what the page requests after it loads. A lot of sites with no public API pull their content from a JSON endpoint that you can call directly. That route is faster than both alternatives and it tends to survive redesigns, because the markup can change completely while the endpoint stays where it is.

The Static Path: Fetch And Cheerio

For a static page the whole job is one HTTP request and a parser. Node's built in fetch gets the HTML, and Cheerio gives you a familiar selector API over it without any of the weight of a real DOM.

const res = await fetch("https://example.com/products", {
  headers: { "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)" }
});
const $ = cheerio.load(await res.text());

const items = $(".product-card").map((i, el) => ({
  name: $(el).find("h2").text().trim(),
  price: $(el).find(".price").text().trim()
})).get();

This runs in milliseconds, uses a few megabytes, and happily handles hundreds of concurrent requests on a single Node process, because the event loop is doing nothing but waiting on sockets. Nothing about a headless browser improves this outcome.

The Dynamic Path: When The Browser Is The Only Way

When content only exists after render, Playwright or Puppeteer stops being overhead and starts being the point. Three habits keep that path from becoming the flaky part of your system.

Wait for a signal, not for a duration. A fixed sleep is a guess that is either too slow or too short. Waiting for the selector you actually need is neither.

Block what you do not read. Images, fonts and media are most of the page weight and none of the data. Aborting those requests often cuts page time by more than half.

Reuse one browser, many contexts. Launching Chromium per URL is the single most expensive mistake in a dynamic scraper. One browser instance with a fresh context per job gives you isolation without the startup cost.

The decision tree behind all of this, along with the libraries for each path, is laid out in more depth in this guide to web scraping with JavaScript.

What Breaks In Production

Scrapers rarely fail on the day you write them. They fail six weeks later, and almost always for one of four reasons.

Selectors that were too specific. div > div:nth-child(3) > span encodes the entire layout. Anchor on text, ids, or data attributes instead, and your scraper survives a redesign that moves things around.

Retry loops with no ceiling. A failing target plus an eager retry is how a polite scraper turns into something that looks like an attack. Cap the attempts, back off exponentially, and log the failure rather than hammering through it.

Concurrency set by wishful thinking. Node will happily open a thousand sockets. The site on the other end will happily stop answering. Pick a concurrency you would be comfortable defending, then add delays between requests.

No schema check on the way out. If a field silently starts coming back empty, you want to know that day, not when someone queries the table a month later and finds a column of nulls.

The Takeaway

The library is not the interesting decision. Whether the page needs a browser at all is the interesting decision, and it is answerable before you write a line of code. Check the raw response first, look for the JSON endpoint second, and reach for the browser third, when the page has genuinely earned it.

The Fee Math Behind An Amazon FBA Listing

Paul Crinigan — Thu, 13 Aug 2026 14:43:31 +0000

If you have ever built tooling around marketplace selling, you have probably written some version of the same function: given a product, what is the actual net per unit. This post walks through that model, because the profit column in most off-the-shelf research tools quietly drops at least one of the three fee layers.

Three Fees, Not One

Amazon takes its cut in three separate places, and they behave differently, which is the whole reason a single blended percentage gives you the wrong answer.

The referral fee is 8 to 15 percent of the selling price depending on category. It is proportional, so it scales cleanly and never surprises you.

The fulfillment fee is roughly $3.22 for a small standard-size item and rises to $10 or more for large heavy ones. This one is effectively fixed per unit within a size tier, and fixed costs sitting against a variable price are exactly where naive models break.

Storage is monthly, charged on volume, and it climbs steeply from October through December. Long-term storage and removal fees stack on top once inventory ages, so a slow mover pays twice, once in carrying cost and once in the capital parked in a warehouse.

Why The $20 To $75 Band Exists

Encode those three and the familiar price band stops being an assumption and becomes an output.

Below about $20 the fixed fulfillment fee is a large fraction of revenue. A $3.22 fee on a $12 item is 27 percent before the referral fee has taken anything, and what remains cannot absorb returns and advertising.

Above about $75 the arithmetic is fine but conversion is not. The purchase stops being an easy yes, so you pay more per conversion in advertising and hand the extra gross margin straight back to the ad platform.

The band experienced sellers quote is simply the range where the fixed component is small enough and the buying friction is still low.

The Plan Choice Is Just A Breakeven

The Professional plan is $39.99 a month, the Individual plan is $0.99 per item sold. The crossover sits at 40 units a month, which is the easy half of the comparison.

The harder half is that the Individual plan does not include advertising, bulk listing tools or Buy Box eligibility. Since the Buy Box is where roughly 83 percent of Amazon sales happen, treating this as a $39.99 decision rather than an eligibility decision is the actual mistake.

What The Model Should Output

Two numbers, not one.

Net per unit after all three fee layers, calculated at a realistic selling price rather than the one you hope to hold. And a demand check: whether the top ten listings in the niche are each moving 300 or more units a month. If they are not, the fee math is irrelevant, because the category is too thin to carry anyone.

The full breakdown of the fees, the four business models and the product criteria is in our Amazon FBA guide, which is the source for the numbers used here.

Getting the order right matters more than getting the model elegant. Run the fee math first, then go looking for a product that survives it.

Marketing Automation For Developers Who Do Not Want To Do Marketing

Paul Crinigan — Thu, 13 Aug 2026 02:12:22 +0000

Marketing is the part of shipping a side project that most developers postpone until launch day, then do badly for a week and quietly abandon. The instinct now is to hand the whole thing to an AI agent. That works, but only for about half of it, and picking the wrong half is why people conclude the tools do not work.

Here is the split that keeps holding up in practice.

What Hands Off Cleanly

The tasks that automate well share one property. They repeat, and you can check the output afterward without much thought.

Site audits are the clearest case. Missing title tags, pages with no meta description, internal links pointing at 404s, images with no alt text, templates that got slow. This is mechanical work with a right answer, so an agent can run it nightly and hand you a diff instead of a report nobody opens.

Follow up sequences are the second. Most solo projects have exactly one email, the welcome message, because writing five more never reaches the top of the list. An agent drafting a five step sequence from your existing docs gets you something to edit, and editing is far faster than starting from an empty box.

Then the plumbing. Segmenting a list by behavior, routing a form submission to the right place, generating the same weekly numbers pull, turning one long piece into the short versions each platform expects. None of it is interesting, all of it compounds, and all of it is verifiable at a glance.

What Breaks When You Automate It

The failures are consistent, and they are not really failures of the model.

If your targeting is wrong, automation scales the wrong targeting. If your positioning is vague, you get fifteen well formatted versions of a vague message. If your offer is not compelling, an agent will happily produce a hundred variants of an offer nobody wants, and the volume makes the underlying problem harder to spot rather than easier.

That is the part worth internalizing. AI is a multiplier on what you already had, so when the output feels off, the fix is almost always upstream of the tool. Nobody enjoys hearing that the problem is the positioning, which is why we keep buying tools instead.

The other consistent break is anything with taste in the loop. Naming, the shape of a launch, deciding which objection to answer first. Those are judgment calls, and a judgment call handed to an agent comes back as an average of everything it has ever seen.

A Practical Order For A One Person Team

Automate in this order, and stop when the next thing needs your judgment.

First the audit, because it runs forever and needs no input from you. Second the follow ups, because a mediocre sequence you actually shipped beats the perfect one still in your head. Third the reporting, because it is the task most likely to silently stop happening the week you get busy.

Keep positioning, pricing and the offer itself in your own hands. Those three decide whether any of the automated work has something worth amplifying.

If you want the longer version with the specific jobs mapped out, we keep a breakdown of AI marketing work that splits the tasks into what hands off cleanly and what still needs a person.

The Takeaway

The question is never whether AI can do marketing. It is which half of your marketing is repetitive and checkable, and which half is a judgment call wearing a task's clothing. Sort the list that way first, and the tooling decision mostly makes itself.

Four Things the Payment Pricing Page Does Not Tell You

Paul Crinigan — Wed, 12 Aug 2026 23:10:13 +0000

If you have ever integrated a payment gateway, you know the SDK is the easy part. The pricing page is where the real complexity hides, and almost none of it shows up in the docs you read while wiring up a checkout.

Here are the four things that actually matter once real money starts moving.

1. Your Rate Is Three Numbers Wearing a Trench Coat

The single percentage you see advertised is three separate fees stacked together.

Interchange is the largest piece and it goes to the bank that issued your customer's card. Visa and Mastercard set it, and nobody in the chain can discount it. In the US it runs from roughly 1.65 percent plus 10 cents on a basic debit card to about 2.40 percent plus 10 cents on a premium rewards card. The effective average for ecommerce lands around 1.8 to 2.1 percent.

Assessments are the card network's own take, about 0.13 to 0.14 percent. Also fixed.

Processor markup is the only piece anyone can actually negotiate. On a flat rate plan it is invisible, folded into the advertised number.

Run the math on a $100 order paid with a rewards card and you get about $2.10 interchange, $0.14 assessment, and $0.25 to $0.50 markup. Call it $2.49 to $2.74. That same order on a 2.9 percent plus 30 cents flat rate costs $3.20.

2. An Approval Is Not Money

The auth round trip, gateway to processor to card network to issuing bank and back, takes about two seconds. What you get back is an authorization, a promise that the funds exist and are reserved.

Settlement is a separate event, usually batched at the end of the business day. This is why your bank deposits never match your daily sales figures, and it is the single most common source of confusion when someone builds their first reconciliation job. If your ledger assumes approved equals deposited, it will drift from day one.

Design for the gap. Store the auth and the settlement as distinct states, and expect the second one to arrive later, sometimes partially, sometimes not at all.

3. Onboarding Speed Is a Risk Trade

Signing up with Stripe, PayPal or Square takes minutes because you are not getting a merchant account. You are being aggregated under theirs. There is no underwriting, no credit check, no monthly minimum.

The cost of that is the risk profile. Because you share the facilitator's account, their automated systems can hold or freeze your funds when something looks unusual, and your appeal path is a support queue.

A traditional merchant account is underwritten specifically for your business. Three to seven days of setup, monthly minimums, statement fees, and interchange-plus pricing where you pay real interchange plus a known markup. Above roughly $20,000 a month in volume, interchange-plus usually wins even after the fixed costs. Below it, the flat rate is honestly a fair price for not having to think about any of this.

4. The Number Nobody Computes

Ask any store owner what they pay and you will get the headline rate. Ask what their effective rate was last month, total fees divided by total volume, and you will usually get a pause.

That single number is the only fair way to compare two processors, because it absorbs the mix of card types your customers actually use, the fixed monthly fees, and every line item you forgot was on the statement. The complete breakdown of gateways, fee structures, settlement and PCI scope walks through the rest of it.

The Takeaway

Do not shop for a lower interchange rate, because it does not exist. Compare markup, weigh the fixed costs against your real volume, and build your reconciliation around the fact that authorization and settlement are two different events that happen at two different times.

What AI Photo Editors Are Actually Doing to Your Image

Paul Crinigan — Wed, 12 Aug 2026 20:58:54 +0000

An AI photo editor is not a filter with better marketing. It is four separate model families stitched behind one interface, and knowing which one is running on a given click explains why some edits come out flawless and others fall apart in ways that feel arbitrary.

Segmentation Is Why Selective Edits Work

Semantic segmentation is the layer that turns pixels into meaning. Instead of a grid of colour values, the model labels regions: this is sky, that is a person, those are trees. Every one-click subject selection, every sky replacement, every "brighten only the background" slider depends on this step being correct.

It is also the easiest capability to benchmark honestly. Load a portrait with flyaway hair against a busy background and select the subject. A strong implementation gives you individual strands with natural edge transitions. A weak one gives you a halo, or eats the hair entirely. That single test predicts more about a tool's day-to-day quality than any feature list.

The same technology drives targeted adjustments that used to require manual masking. Lightroom's adaptive presets analyse each photo individually rather than applying uniform changes across a batch, which is only possible because the model knows what it is looking at.

Diffusion Replaced GANs for Generative Fill

Object removal is inpainting. You select the powerline or the stranger in the background, the model deletes it and generates replacement content from the surrounding context.

For several years generative adversarial networks did this work. A generator invented content and a discriminator judged whether it looked real, and the two trained against each other until the output was convincing. Diffusion models have largely displaced them. These learn to reverse a gradual noising process, starting from noise and iteratively refining toward something coherent, which turns out to produce more stable and controllable results.

The practical difference shows up on repeating patterns. Try removing an object from a brick wall or a tiled floor. Weaker implementations smear the pattern or lose the grid alignment, because they are generating plausible texture without understanding the structure it belongs to. This is also the failure case worth testing before you trust a tool with client work.

Upscaling Invents Detail That Was Never There

Super-resolution networks train on pairs of low and high resolution images until they can predict what the missing detail should look like. Modern implementations convincingly enlarge an image by four times or more.

The word "predict" is doing all the work in that sentence. Upscaling does not recover information from the file, because the information is not in the file. It fabricates plausible information consistent with what the model has seen before. For a heavily cropped shot, a print enlargement, or a grainy old family photo, that is exactly what you want. For anything that might need to serve as evidence, it is a quiet disaster, and the output looks more trustworthy than the input rather than less.

Generative fill sits in the same category and is the most oversold feature in the category, because demo results are cherry-picked hard.

Pick the Capability, Not the Product

Because the feature lists have converged, review roundups tend to rank tools that are not really competitors. A product photographer lives in segmentation and colour work. Someone restoring family archives needs super-resolution and inpainting and almost nothing else. A marketing team wants generative fill and background replacement. Those are three different purchases.

Work out which of the four capabilities your actual workload needs, then test that one capability hard on your own worst-case files rather than on the sample images the vendor supplies. Our rundown of AI photo editors breaks down which tools lead on each capability and where the free tiers quietly cap you.

One last practical note that catches people out: check export resolution on free plans before you build a workflow. Several well-known tools display a full-size preview and then hand you a downsized file unless you upgrade, which you tend to discover at the worst possible moment.

What Self Hosted Messaging Software Has To Get Right

Paul Crinigan — Wed, 12 Aug 2026 17:19:55 +0000

Every team that self hosts something eventually finds out which part of the product was the actual product. With messaging software it is almost never the send call. Sending a text is a single HTTP request. Everything that makes a broadcast work sits around that request.

Why Teams Move Off Hosted Platforms

Two reasons come up over and over, and only one of them is cost. The obvious one is the monthly platform fee sitting on top of the per message rate you are already paying your provider. The less obvious one, and the one people care about more once they have been burned, is that the subscriber list lives inside someone else's system.

A list you cannot export cleanly is a list you are renting. Pricing changes, terms change, and accounts get suspended for reasons that have nothing to do with what you sent. Self hosting moves that risk onto your own server, where you control it.

Pacing Decides Deliverability

The failure mode that catches most people building their own broadcast tool is sending everything at once. It feels correct. You have ten thousand contacts and a message, so you loop and send. Carriers read that pattern as exactly what it looks like, and the delivery rate falls off a cliff.

A broadcast should be spread across the day in batches rather than dumped in one burst, and each message should land at a reasonable local hour for the person receiving it. Someone in a different timezone getting a text at three in the morning unsubscribes, and that unsubscribe was avoidable.

What Has To Be Built In Rather Than Bolted On

Opt-out handling is the clearest example. STOP has to work automatically and permanently, on the first message, without anyone reviewing a queue. Treating it as something you will add later is how a self hosted setup turns into a compliance problem.

Drip sequences are the other one. A subscriber joining on day forty should get the same series as one who joined on day one, on their own clock rather than the calendar's. That is state per subscriber, and retrofitting it into a system that only knows how to send a blast is harder than building it in from the start.

We released the engine behind our own texting app as free open source software under MIT, and the write up covers how the batching, drip scheduling and opt-out handling actually work.

The Takeaway

If you are weighing whether to self host your messaging, the question is not whether you can send a message from your own server. You can, in about ten lines. The question is whether the thing you run handles pacing, timezones, opt-outs and per subscriber state without you supervising it. That is the whole difference between a script and software.