DEV Community: Sonia Bobrik

Your Feature Has a Cost Per Execution. Why Isn’t It in the Code?

Sonia Bobrik — Tue, 18 Aug 2026 15:30:38 +0000

A strange thing happens inside modern software companies: engineers can tell you the latency of an endpoint to the millisecond, but often nobody can tell you what executing that endpoint actually costs. That gap matters more than it used to. The broader financial discipline described in Business Finance That Actually Prevents Failure becomes much more concrete when applied at the software layer, because a growing number of products now accumulate real costs every time a user clicks a button, uploads a file, generates an image, runs a search, sends a message, or asks an AI model a question. A feature can be technically successful, heavily used, loved by customers—and economically terrible.

For decades, software benefited from an attractive assumption: once the product was built, serving one more user was comparatively cheap.

That assumption has not disappeared, but it has become dangerously unreliable.

A modern application may call an LLM, invoke an OCR service, generate embeddings, query a vector database, send an SMS, use a geocoding API, process an image, write logs to an observability platform, transfer data across regions, run a serverless function, store the result, and pay a transaction fee before the user sees a single response.

Each component might look inexpensive in isolation.

The feature is not.

We Still Design Features as if Compute Were Free

Imagine a startup selling an AI document-analysis product for $49 per month.

The product team launches a feature called “Deep Review.” Users upload contracts and receive a detailed analysis.

Engagement is excellent.

Customers love it.

Usage grows rapidly.

Everyone celebrates.

But one Deep Review is not one operation. Behind the button, the system might extract text, classify pages, call a large model several times, generate embeddings, search stored context, call another model to verify the answer, save the output, and retain the source document.

Assume, purely as an example, that an ordinary review costs the company $0.18 to process.

That sounds irrelevant.

Then someone uploads a huge document.

It needs multiple OCR passes. Chunking creates dozens of model calls. A retry fires after one provider times out. The verification step receives far more context than expected. That review costs $1.40.

A customer on the $49 plan runs 70 of them.

The customer has paid $49.

The company may have spent close to the entire subscription price on one feature before paying for databases, support, engineering, payment processing, salaries, or anything else.

The feature has not failed.

Its economics have.

This is one of the most important architectural changes developers need to recognize: in a metered software stack, product behavior and financial behavior are no longer separate systems.

“Cloud Bill” Is Too Coarse a Data Type

A monthly infrastructure bill tells you approximately as much about product economics as total CPU utilization tells you about which endpoint is slow.

You need attribution.

If the company spends $80,000 on infrastructure, the interesting questions are not limited to “Why is AWS expensive?” or “Can we reduce the bill by 10%?”

The interesting questions are:

Which customers caused the spend?

Which workflows caused it?

Which product tier generated it?

Which release changed it?

Which feature creates the highest gross profit?

Which popular feature becomes less profitable as usage increases?

Which customer appears valuable in the CRM but loses money after its actual resource consumption is included?

This is not merely a finance problem. AWS’s work on SaaS cost attribution makes the architectural implication clear: understanding resource consumption at the tenant and feature level can influence pricing, product decisions, and architecture itself.

That is a radically better framing than “engineering needs to reduce cloud costs.”

Cost is not something finance discovers after engineering has finished building.

Cost is an output of the architecture.

Cost Should Travel With the Request

Most applications already propagate context through their systems.

A request may carry a user ID, tenant ID, trace ID, session ID, request ID, experiment ID, region, and application version.

Why not economic context?

Suppose an AI workflow generates an event after each billable or resource-intensive operation:

{
  "tenant_id": "tenant_482",
  "feature": "deep_review",
  "operation": "contract_analysis",
  "provider": "model_provider",
  "model": "large_model",
  "input_units": 43820,
  "output_units": 6140,
  "estimated_cost": 0.173,
  "request_id": "req_91af",
  "release": "2026.08.18"
}

This is not intended to replace the provider's invoice.

It solves a different problem.

The invoice tells you what the company owes.

Application-level cost attribution tells you what created the obligation.

Once that information exists, entirely new questions become easy to answer.

You can compare feature revenue with feature cost. You can identify customers whose usage patterns are structurally different from everyone else's. You can discover that a new release increased the cost of a workflow. You can compare two implementations not only on latency but on cost per successful outcome.

Most importantly, engineers gain a feedback loop.

Without that loop, architecture has financial side effects that remain invisible until someone notices the monthly bill.

The Most Dangerous Customer May Be Your “Best” Customer

SaaS dashboards train teams to celebrate heavy users.

More sessions.

More queries.

An Infinite Loop Can Now Appear on the Income Statement

Software engineers already protect systems against technical runaway conditions.

We limit recursion.

We set timeouts.

We cap retries.

We rate-limit APIs.

We kill jobs that run for too long.

We stop queues from expanding indefinitely.

But consider an AI agent.

The agent receives a task, calls a model, invokes a tool, reads the result, decides it needs more information, calls another tool, queries the model again, retries an unsuccessful step, expands its context, and repeats the cycle.

From a technical perspective, the workflow may still be functioning exactly as designed.

From an economic perspective, it may have entered a runaway loop.

This produces a new category of engineering requirement: financial bounds.

An operation should not only have a timeout. It may need a cost ceiling.

A job should not only have a maximum retry count. It may need a maximum cumulative inference budget.

A customer should not only have an API rate limit. The application may need a resource budget based on the economics of the customer's plan.

A feature should not only satisfy latency and reliability requirements. It may need an acceptable cost-per-successful-execution range.

That sounds obvious once stated.

It is rarely treated as a first-class software requirement.

Put Economics Into the Pull Request

Here is where things get more interesting.

Suppose a developer improves an AI workflow.

The old implementation makes one expensive model call.

The new implementation performs five smaller calls because the developer discovers that decomposition improves answer quality.

The accuracy benchmark improves 8%.

The latency remains acceptable.

Tests pass.

The pull request looks excellent.

But suppose the cost per successful workflow rises from $0.11 to $0.39.

Is the new version better?

There is no universal answer.

If customers pay $20 every time the workflow succeeds, almost certainly.

If it is included without limits inside a $9 monthly plan, perhaps not.

The point is that the economic regression belongs in the engineering discussion.

Teams already reject code because it creates unacceptable latency, memory consumption, security exposure, or reliability risk.

Why should a 250% increase in variable cost remain invisible?

For measurable workflows, teams can go surprisingly far with simple tooling.

A benchmark suite can record the number of external calls.

It can record input and output units.

It can estimate compute duration.

It can compare those values with a baseline.

It can flag a pull request that makes a common workflow dramatically more expensive.

Not every cost estimate will be perfect. It does not need to be.

A smoke detector does not need to calculate the insurance value of the house before it becomes useful.

The Database Query That Saves $50,000 Is Still an Optimization

Developers frequently debate optimization using technical language.

This query is 200 milliseconds faster.

This cache reduces database load.

This architecture supports more requests per second.

This model produces better answers.

Those are legitimate improvements.

But at sufficient scale, some of the highest-impact performance work may be invisible when measured only in milliseconds.

Imagine that a high-volume request performs three redundant database operations. Removing them saves an amount so small per request that nobody cares during development.

Multiply that amount across hundreds of millions of executions.

Now it matters.

Or imagine that an image-processing workflow keeps the original, intermediate files, generated variants, and debug artifacts forever.

Nothing breaks.

Storage simply compounds.

Or a tracing configuration sends huge payloads for successful requests that nobody will ever inspect.

Or an AI application sends an entire conversation history back to a model even when only a small section is relevant.

Technically, the product works.

Economically, the implementation contains waste.

The important shift is not “developers should always choose the cheapest architecture.”

That would be bad engineering.

The shift is: developers should be able to see the economic consequence of architectural choices.

Sometimes paying more is absolutely correct.

A more expensive model may improve conversion enough to justify itself.

Additional redundancy may be essential for reliability.

Lower latency may generate enough business value to justify significantly higher infrastructure spend.

Premium observability may reduce incident duration.

The goal is not minimum cost.

The goal is deliberate cost.

“Unlimited” Is an Engineering Decision

Product teams love the word “unlimited.”

Customers do too.

Engineers should hear something else when they see it:

What technically prevents one user from consuming 10,000 times more resources than another user paying the same price?

Sometimes the answer is that nothing prevents it because marginal cost really is negligible.

Fine.

Sometimes the answer is that extreme usage is statistically rare enough that the economics still work.

Also fine.

But sometimes “unlimited” simply means nobody modeled the tail.

Average users are frequently irrelevant to infrastructure risk. Outliers matter.

The same principle appears in performance engineering.

A system with a 100 ms average response time can still be terrible if its tail latency is 12 seconds.

Product economics also have tails.

The average customer may cost $6 per month to serve while the top one percent costs $90.

If pricing was designed around the average, growth can gradually select for the customers who exploit the mismatch most effectively.

That is not abuse.

They are using the product you sold them.

Build a Cost Map Before You Build a Cost Dashboard

You do not need a massive FinOps implementation to start.

You need to understand where money enters the execution path.

For one important customer action, trace the full chain from click to result and identify every resource whose cost changes with usage.

For example:

Trigger: user requests a video analysis
Variable work: upload, transcoding, model inference, object storage, database operations, data transfer, notifications
Cost driver: video duration, resolution, model runtime, generated output size
Customer dimension: tenant, plan, geography, contract type
Product dimension: feature, workflow version, experiment
Business output: successful analysis, revenue associated with usage, gross contribution

That is the only list this article needs because the important part comes afterward.

Instrument one workflow.

Not the entire company.

Pick the feature that is expensive, rapidly growing, strategically important, or difficult to understand.

Then ask a question most teams cannot currently answer:

What happens to our gross profit if usage of this exact feature increases 10x tomorrow?

If the answer requires three people, two spreadsheets, a cloud invoice, and a week of analysis, the architecture is hiding business-critical information.

The Best Architecture May Depend on Who Is Using It

Cost attribution also complicates a sacred engineering instinct: finding the single “best” implementation.

There may not be one.

An enterprise customer paying $50,000 per year might justify a computationally expensive workflow that produces the highest possible accuracy.

A self-service customer paying $12 per month may need a different model, smaller context window, lower retention period, asynchronous processing, or stricter usage limits.

That is not necessarily an inferior product.

It is resource allocation.

Cloud architecture already changes resources according to workload. Product architecture can do the same according to economics.

Model routing is an obvious example.

A request does not automatically need the most capable model available.

A lightweight classification might go to a smaller model. An ambiguous case can escalate. A high-value workflow can justify a more expensive path. Repeated context can be cached. Inputs can be compressed. Work that does not require immediate completion can be batched.

The interesting engineering problem becomes:

What is the cheapest execution path that still delivers the required outcome?

That is much better than asking engineers to “cut AI costs.”

Your Unit Test Knows Whether the Function Works. It Could Also Know Whether the Business Model Still Works.

Software development has spent decades moving failure detection earlier.

We moved testing from users to QA.

Then from QA to automated test suites.

Then into continuous integration.

We moved security checks into development pipelines.

We moved dependency scanning into pull requests.

We moved performance benchmarks closer to the code.

The same direction makes sense for variable product economics.

A feature whose economics are only discovered on a monthly invoice has a feedback loop measured in weeks.

A feature whose resource consumption is measured during development has a feedback loop measured in minutes.

That does not mean putting the CFO in GitHub.

It means recognizing a simple truth:

In modern metered software, cost is increasingly a runtime property.

Runtime properties belong close to engineering.

The Next Generation of Great Developers Will Understand the Machine and the Meter

There was a period when a developer could reasonably treat infrastructure economics as someone else's concern.

Servers were purchased centrally. Finance handled contracts. Product set pricing. Engineering built the application.

Cloud computing already weakened that separation.

Serverless weakened it further.

API-first software weakened it again.

AI may finally destroy it.

A developer can now add a few lines of code and change the company's variable cost structure instantly. Choosing a different model, changing context length, adding a second validation pass, moving data between regions, retaining files longer, increasing observability volume, or introducing a third-party API can alter the economics of a feature without changing its price by one cent.

That gives engineers more responsibility.

It also gives them more influence.

The developer who can say, “This version is faster,” is useful.

The developer who can say, “This version is faster, improves successful completion by 6%, and reduces cost per successful task by 31%,” is participating in the business at an entirely different level.

The future of software engineering is not about turning developers into accountants.

It is about giving architecture one more observable property.

We already measure whether software works.

We measure how fast it works.

We measure whether it is available.

We measure whether it is secure.

Now, for the growing class of software in which every meaningful action consumes metered resources, we should measure one more thing:

Was executing it worth what it cost?

The Most Dangerous File in Your Repo Might Be SECURITY.md

Sonia Bobrik — Tue, 18 Aug 2026 12:41:53 +0000

Developers write far more legally consequential prose than they think, and almost none of it is code. It's the SECURITY.md in the repo root. It's the "Security" page someone in marketing asked you to fill in three years ago. It's the status page update typed at 2 a.m., and the sentence in a customer notice specifying exactly which data was affected. The research summarized in this overview of what the evidence shows about cyber incident disclosure treats post-breach communication as a measurable discipline with predictable failure modes — and the enforcement record of the last three years has quietly turned it into an engineering discipline too. In the most closely watched cybersecurity case of the decade, the only allegation that survived a motion to dismiss concerned a technical description of access controls posted on a website.

The claim that survived was written by engineers

On July 18, 2024, Judge Paul Engelmayer of the Southern District of New York issued a 107-page opinion in the SEC's case against SolarWinds and its CISO. Most of it was a defeat for the agency. Claims built on blog posts, press releases, and podcast appearances were dismissed as non-actionable corporate puffery — statements too general for any reasonable investor to lean on. The theory that cybersecurity controls fall under "internal accounting controls" was rejected outright. Post-incident 8-K disclosures were held to be reasonable given what was knowable at the time.

One thing lived: the company's "Security Statement," a technical page describing its practices to customers. The court let claims proceed specifically on its representations about access controls and password policy, because those were concrete enough to rely on and, as pled, contradicted by internal presentations, security assessments, and Slack messages. The SEC ultimately dismissed the whole action with prejudice in November 2025, so no liability was ever established — but the legal line drawn in 2024 didn't go anywhere. Vague marketing language is protected precisely because it says nothing. The specific, verifiable technical claim is the one with teeth.

Read that sentence again if you maintain a trust page. "We take security seriously" is legally inert. "All administrative access requires MFA" is a factual assertion about your infrastructure that someone will one day compare against your actual IAM configuration, your Jira backlog, and your team's Slack history.

A file-name review became a false public statement

The second case is more uncomfortable, because the mistake was a technical judgment call that any of us could make under pressure.

Blackbaud discovered a ransomware intrusion in May 2020. To scope it, technology staff reviewed the names of exfiltrated files rather than analyzing their contents. Based on that review, the company posted a notice in July 2020 telling customers the attacker had not accessed bank account information or Social Security numbers. Then customers began writing in — over a thousand messages — many pointing out that they had entered sensitive data into fields the software did not encrypt. Deeper analysis confirmed unencrypted bank account details and Social Security numbers had in fact been taken. That finding never reached the people responsible for the company's public disclosures, and the website statement stayed uncorrected while a later quarterly filing described data-exfiltration risk as hypothetical. The SEC's settled order imposed a $3 million penalty in March 2023, without alleging intentional misconduct.

There is no villain in that story. There is a scoping shortcut, a schema assumption ("that field holds notes, not SSNs"), and a missing edge in the org chart between the person who learned the truth and the person who had published the falsehood. All three are engineering artifacts.

It is not only a public-company problem

Anyone at a startup assuming this is a Fortune 500 concern should read the FTC's finalized order against GoDaddy from May 2025. The agency's theory was straightforward: the company advertised "award-winning security" while lacking multi-factor authentication, threat monitoring, and secure connections for customer data. Section 5 of the FTC Act reaches any company making deceptive claims, private or public, seed-stage or not. The remedy reads like a backlog someone else wrote for you — mandatory MFA including at least one method that doesn't require a phone number, HTTPS on APIs handling covered information, an update-management program, biennial third-party assessments, and incident reporting to the Commission within ten days.

Why silence is not the safe default

The instinct after reading all this is to say nothing about security anywhere, ever. The empirical record argues the opposite. In a study published in the Review of Accounting Studies, Amir, Levi, and Livne compared attacks companies disclosed themselves against attacks that were concealed and later surfaced by outsiders. Withheld incidents were associated with roughly a 3.6% decline in equity value in the month of discovery; disclosed incidents, around 0.7%. Their model also suggested managers tend to speak only once outsiders already suspect an attack with about 40% probability — meaning the incidents that stay hidden skew toward the severe ones, and the "breaches don't really hurt stock prices" folk wisdom is built largely on the mild cases that got announced.

So the goal is not silence. It is writing things that stay true under adversarial reading:

Describe controls that are enforced, not intended. If MFA is required for 94% of admin accounts, the honest sentence names the exception. A published claim your own audit log contradicts is the exact shape of every case above.
Version your security page like code. Keep it in the repo, require review, and let git log prove when each claim was accurate. An undated marketing page is a permanent unqualified assertion.
Never scope a breach by metadata alone. File names, table names, and bucket paths describe intent, not contents. Users put card numbers in "comments" fields. Verify before publishing a negative.
Prefer "we have confirmed X" over "Y did not happen." Negative claims require exhaustive verification; positive claims about confirmed findings age gracefully as the investigation continues.
Make correction a defined path, not a favor. Whoever discovers the earlier statement was wrong needs a named recipient and an obligation to use it. Blackbaud's penalty rests substantially on that link being absent.
Assume Slack is exhibit A. Internal messages contradicting public claims were central to the surviving SolarWinds allegation. Write internally as though it will be read aloud, not because you're hiding anything, but because accurate internal writing is what makes accurate public writing possible.

The uncomfortable summary

Nothing in the enforcement record punishes being breached. Courts and regulators accept that competent organizations get compromised. What draws liability is the delta between what a company published about itself and what its own engineers knew — a gap authored, almost always, by people writing documentation rather than exploits.

The fix isn't legal review of everything. It's treating security documentation as a claim about a system, with the same expectation of verification you'd apply to any other assertion about production. If you can't point to the control that makes a sentence true, delete the sentence.

The Engineering Principle Your Startup's Balance Sheet Is Missing

Sonia Bobrik — Tue, 18 Aug 2026 12:36:54 +0000

Developers spend years internalizing a simple truth: unreadable code eventually kills a project, no matter how clever it is. What most of us never notice is that the same law governs the business wrapped around our code, and a recent piece arguing that the real financial edge is legibility, not growth, makes that connection impossible to ignore. A company whose finances cannot be read quickly by an investor, a lender, or a senior engineer deciding whether to accept an offer is carrying the corporate equivalent of a 4,000-line function with no tests. It might run today. Nobody can safely bet on it tomorrow.

Why Engineers Should Care About a Finance Concept

If you write software for a living, your salary, your equity, and your roadmap all sit downstream of decisions made by people reading your company's numbers. When those numbers are confusing, the confusion does not stay in the finance department. It shows up as a hiring freeze announced without warning, a "strategic pivot" that kills the service you spent a year building, or a funding round that closes on brutal terms because investors priced in uncertainty.

Paul Graham captured the core question years ago in his essay on whether a startup is default alive or default dead: given current growth and current spending, does the company reach profitability before the money runs out? What is striking about that framing is how few founders can answer it, and how few engineers ever think to ask. Legibility starts exactly there. A financially legible company can answer that question in one sentence, with numbers, on any given Tuesday.

The parallel to software is almost mechanical. Technical debt is the gap between how a system behaves and how easily that behavior can be understood. Financial illegibility is the gap between how a business performs and how easily that performance can be verified. Both compound quietly. Both feel free right up until the moment someone external needs to evaluate you, whether that is a new team member reading the codebase or a bank reading the ledger.

Reading a Company the Way You Read a Codebase

Engineers already own the mental tools for this. You know how to trace data flow, distinguish signal from noise, and spot the difference between a system that works and a system that merely demos well. Applied to a business, that skill set translates into a short review checklist worth running before you join a startup, accept equity in place of cash, or push your own side project toward incorporation:

Trace the cash, not the revenue. Revenue is a promise; cash arriving in the account is the merged pull request. Ask how long the gap is between "customer signed" and "money landed."
Check the dependencies. One customer generating 40% of income is a single point of failure, exactly like one unmaintained library holding up production.
Look for observability. Can leadership produce current runway, gross margin, and burn within a day? If the answer requires "pulling some things together," the monitoring stack is fiction.
Read the error handling. How does the company behave when a big invoice is paid late? Improvised panic is a smell; a documented playbook is a feature.
Inspect the interfaces. Do the story told to investors, the story told to employees, and the actual ledger describe the same system? Divergence between docs and code is always a warning.

That is the only list you need, because the underlying move is singular: treat the business as a system under review and refuse to accept "trust me, it's fine" as a substitute for readable state.

Working Capital Is Just Memory Management

The least glamorous concept in this whole domain turns out to be the most decisive one. Working capital, which Investopedia defines cleanly as the difference between current assets and current liabilities, is effectively a company's available RAM. Inventory sitting in a warehouse is allocated memory doing nothing. Unpaid invoices are pointers to money that exists in theory. A business can post impressive growth while leaking working capital the way a service leaks memory: everything looks fine on the dashboard until the process gets killed at 3 a.m.

For anyone freelancing or running a small SaaS, this stops being an analogy and becomes daily reality. Invoicing the day work ships, setting payment terms before delivery rather than after, and knowing your personal runway to the week are not accounting chores. They are the financial equivalent of writing tests before merging: small disciplines that make your entire operation auditable by anyone, including future you.

Legibility Is a Feature You Can Ship

Here is the optimistic ending, and it is genuinely optimistic. Unlike growth, which depends heavily on market luck, legibility is fully within your control. You can ship it. A one-page document explaining how your project makes money, a spreadsheet that reconciles with the bank account, a public changelog of pricing decisions, a straight answer to the default-alive question: each of these is a pull request against the fog.

The companies and the individual developers who win the next few years will not necessarily be the fastest-growing ones. They will be the ones that are easiest to believe, because every claim they make can be traced to evidence in constant time. Make your finances as readable as you wish every codebase were, and you will have built the rarest asset in a skeptical market: a story that survives code review.

Why Media Exposure Is the Underrated Growth Lever Most Technical Founders Ignore

Sonia Bobrik — Tue, 18 Aug 2026 12:36:30 +0000

Every developer who has ever shipped a side project knows the painful silence that follows a launch: the code works, the product solves a real problem, and yet nobody outside your immediate circle seems to notice. Most technical founders respond by writing more code, when the real bottleneck is visibility — and as a detailed breakdown of PR as a gateway to investors and strategic partners explains, earned media coverage is often the single most efficient way to put your project in front of the exact people who can fund it, integrate with it, or acquire it. This is not marketing fluff. It is a measurable input into how investors and partners evaluate risk, and it deserves the same engineering mindset you apply to everything else you build.

The Due Diligence Problem You Didn't Know You Had

Here is an uncomfortable truth: before any investor or potential partner takes a meeting with you, they Google you. If that search returns an empty page — no articles, no interviews, no independent mention of your product anywhere — it raises questions. Have you been building in stealth? Is there no market interest? Is the founder unable to articulate the story?

Silence reads as risk. A single feature in a respected publication, on the other hand, works as third-party validation: an editor with no financial stake in your success decided your story was worth telling. That signal cannot be bought with ad spend, which is precisely why it carries weight. Research consistently shows that audiences — and investors are an audience too — trust independent editorial voices far more than paid promotion, a point argued convincingly in Forbes' analysis of why earned media still outperforms paid channels when trust matters most. For a bootstrapped developer, this is excellent news: credibility is one of the few growth assets that does not require a marketing budget.

How Coverage Compounds Like Technical Debt in Reverse

Think of media exposure as the inverse of technical debt. Each placement is a small commit to a public repository of trust, and the interest compounds in your favor. One article leads to a podcast invitation. The podcast leads to a conference panel. The panel puts you in a hallway conversation with a partner at a fund who read that first article six months ago. None of these steps is dramatic on its own, but the chain reaction is what opens doors that cold emails never will.

There is also a very modern twist: AI assistants and answer engines increasingly synthesize their recommendations from earned media. When a potential customer or investor asks a chatbot "who are the interesting players in this space," the companies that appear are the ones with a documented public footprint. Your press coverage is now training data for the systems advising your future stakeholders.

A Practical Playbook for Developers Who Hate Self-Promotion

You do not need an agency or a rolodex of journalists to get started. You need a story that is genuinely useful to a reporter's readers, delivered without jargon. Here is a minimal viable approach:

Lead with data you own. Usage metrics, benchmark results, or an unexpected trend from your logs give journalists something exclusive they cannot get elsewhere.
Write the post-mortem nobody else will. Honest accounts of failures, migrations, and hard trade-offs are catnip for tech media and build more credibility than any success story.
Target tier-appropriate outlets first. A niche developer publication that actually covers your category beats a long-shot pitch to a national outlet, and it becomes proof for the next, bigger pitch.
Time announcements around milestones. Funding rounds, major releases, and notable customer wins give editors a news hook and give investors a reason to look twice.
Make yourself quotable. Short, opinionated, technically grounded commentary on industry news positions you as a source journalists return to.

The pattern behind all five tactics is the same: give before you ask. Journalists are drowning in pitches that say "cover me"; they respond to pitches that say "here is something your readers will thank you for."

The Investor Math Behind a Headline

Skeptical engineers reasonably ask whether any of this moves real numbers. The evidence says yes. Companies that build media presence before a raise consistently report faster fundraising cycles and stronger inbound interest, because coverage converts a cold pitch into a warm one — the investor has already encountered your name in a context they trust. Entrepreneur's examination of how public relations sparks growth and credibility for startups reaches the same conclusion: meaningful press in respected outlets directly increases investor confidence and strengthens a company's position in funding and acquisition conversations.

None of this replaces building a great product. But if you have already done the hard part — shipping something people need — then staying invisible is a choice, and an expensive one. Treat visibility as part of your stack. Instrument it, iterate on it, and let each piece of coverage do what good infrastructure always does: quietly open doors while you sleep.

Why Your Architecture Now Matters More Than Your Model

Sonia Bobrik — Tue, 18 Aug 2026 12:35:55 +0000

For the past few years, engineering conversations have been dominated by a single question: which model is best? Teams argued over benchmarks, swapped API keys the moment a new release dropped, and treated model choice as the decisive factor in product quality. That era is ending. A recent discussion on why the next technology advantage will come from systems, not models captures the shift precisely: as frontier models converge in capability, the durable edge moves to the layer around the model — retrieval, orchestration, evaluation, feedback loops, and the unglamorous plumbing that turns raw intelligence into a dependable product. If you build software today, this reframing should change how you spend your engineering hours.

Models Are Becoming a Commodity Layer

Look at any capability benchmark from the last eighteen months and a pattern emerges: the gap between top-tier models keeps shrinking, and the gap between a given model today and the same family six months ago keeps widening. Whatever advantage you gain by picking "the best" model evaporates on the next release cycle — often in weeks. Meanwhile, switching costs between providers keep falling because APIs look increasingly alike.

What does not evaporate is the system you build around the model. Your retrieval pipeline that surfaces the right context at the right moment. Your evaluation harness that catches regressions before users do. Your fallback logic, your caching strategy, your guardrails, your data flywheel. These compound. A competitor can adopt your model tomorrow; they cannot adopt your two years of accumulated system design overnight.

The Lesson Engineers Learned a Decade Ago

None of this is actually new. Researchers at Google warned about it back in 2015, in the now-classic paper on hidden technical debt in machine learning systems, which showed that the learning code itself is a tiny black box in the middle of a sprawling diagram of configuration, data verification, serving infrastructure, and monitoring. The model was never the hard part. The system was. Large language models did not repeal that finding — they amplified it, because prompts, context windows, and non-deterministic outputs introduce entirely new categories of entanglement and silent failure.

The practical implication is uncomfortable for teams that have organized themselves around model selection. If ninety percent of your production risk lives outside the model, then ninety percent of your engineering attention should live there too.

Where the Real Leverage Hides

So what does "investing in the system" actually mean day to day? In my experience reviewing AI-heavy codebases, the highest-leverage work clusters in a few places:

Evaluation before optimization. Teams that cannot measure output quality end up arguing from vibes. A few hundred labeled examples and an automated eval loop beat any amount of prompt tinkering, because they tell you whether a change helped at all.
Context engineering over prompt engineering. The single biggest driver of answer quality is usually what information reaches the model, not how politely you ask. Retrieval quality, chunking strategy, and freshness of source data deserve real design reviews.
Graceful degradation. Timeouts, malformed outputs, and rate limits are certainties, not edge cases. Systems that retry intelligently, fall back to cheaper models, or fail visibly earn user trust that no benchmark score can buy.
Feedback capture. Every user correction is training signal. Products that log it, structure it, and route it back into evals build a moat that widens with usage.

Notice that none of these items require frontier research. They require the same disciplines — testing, observability, incremental design — that good engineers already practice, applied to a stochastic component.

The Human Side of the System

There is one more component in every AI system that rarely appears in architecture diagrams: the people operating it. Harvard Business School professor Karim Lakhani put it memorably when he argued that AI won't replace humans, but humans with AI will replace humans without it. Translated into engineering terms, the organizations that win are the ones where developers, reviewers, and domain experts are woven into the loop — labeling edge cases, auditing outputs, and continuously teaching the system what "good" looks like. A brilliant model dropped into a team with no review culture produces confident garbage at scale. A merely decent model embedded in a well-designed sociotechnical loop improves every single week.

What to Do Differently Starting Monday

Stop asking "which model should we use?" as your opening question. Ask instead: how will we know if output quality drops? Where does our context come from, and how stale is it? What happens when the API fails at 2 a.m.? Who reviews the cases the system gets wrong, and where does that knowledge go? Answer those four questions well and the model becomes what it was always destined to be — a swappable part inside something much harder to copy. The advantage was never in the weights. It is in the wiring, and the wiring is yours to build.

Why Engineers Who Ignore PR Are Leaving Growth on the Table

Sonia Bobrik — Tue, 18 Aug 2026 12:35:28 +0000

Most developers treat public relations the way they treat legacy code: someone else's problem, best avoided. You ship the product, the marketing team "does the talking," and the two worlds rarely meet. But if you've ever launched a side project into total silence, you already know that great engineering doesn't distribute itself. A thoughtful breakdown of strategic PR as a growth tool makes a point worth internalizing early: reputation compounds like interest, and the teams that plan for it deliberately grow faster than the teams that hope for it. This article is about what that means in practice for people who write code for a living.

PR Is Infrastructure, Not Decoration

Think of public relations the way you think about observability. Nobody needs logging until something breaks, and nobody needs a reputation until a customer, investor, or hiring manager googles you. By then it's too late to start building one.

The mechanics are surprisingly close to systems design. A press mention is a cache hit: someone else's audience discovers you without you paying for the impression. A founder's technical blog post is a long-lived service: it keeps answering requests years after deployment. A crisis response is your incident runbook: if you write it during the outage, you've already lost. The teams that win treat all of this as infrastructure built before it's needed, not decoration bolted on after launch.

There's hard data behind the intuition. The 2026 Edelman Trust Barometer found that people worldwide are retreating into smaller, more insular circles of trust — 70% are hesitant to trust anyone whose values or background differ from their own. For a startup, that's a brutal environment: strangers don't extend benefit of the doubt anymore. The only reliable way through is third-party validation — coverage, community reputation, and voices your audience already trusts vouching for you. That is precisely what strategic PR manufactures.

What "Strategic" Actually Means for a Technical Team

The word "strategic" separates PR from noise. Spraying press releases at journalists is the marketing equivalent of committing directly to main and hoping CI catches it. A strategy has a target state, constraints, and a feedback loop.

For a developer-led company, that usually looks like this:

Pick one narrative and repeat it relentlessly. "We make Postgres backups boring" beats five clever taglines. Journalists, users, and search engines all reward consistency.
Publish engineering content that only you could write. Post-mortems, benchmark deep-dives, migration war stories. This is the rare PR channel where technical honesty is the differentiator.
Instrument everything. Track referral traffic, branded search volume, and inbound demo requests after each placement. If you can't measure a channel, you can't justify it — the same rule you apply to features.
Prepare the crisis playbook now. Draft the security-incident statement before the incident. Decide who speaks, on which channel, within what SLA. Calm, fast, honest responses have saved companies that slow silence would have killed.

Notice what's absent: buying followers, chasing virality, gaming anything. Strategic PR is boring in the way good infrastructure is boring — deliberate inputs, compounding outputs.

The Trust Dividend Nobody Budgets For

Here's the part that rarely makes it into a quarterly plan. Trust doesn't just make selling easier; it lowers the cost of everything. Recruiting gets cheaper because candidates arrive pre-convinced. Partnerships close faster because due diligence starts from goodwill. Even fundraising terms improve, because investors price risk, and reputation is risk reduction they can see.

Harvard Business Review's ongoing coverage of public relations and stakeholder trust keeps circling one uncomfortable finding: only about a third of consumers trust the brands they use, and public-facing communication is often what tips the balance between the trusted third and everyone else. If you want the praise when things go well, you have to build the credibility to survive when they don't. That trade is the entire business case for doing PR on purpose.

Start Smaller Than You Think

You don't need an agency retainer to begin. Write one genuinely useful technical post this month. Answer one journalist's request for expert comment. Document one architectural decision publicly. Each artifact is a small deposit into an account that pays out at the exact moment you need it most — a launch, a funding round, a bad day.

Engineers already understand compounding systems better than almost anyone. Reputation is just another one. The only mistake is waiting until you need it to start building it.

Why Every Developer Should Understand Cryptocurrency Before Writing a Single Line of Web3 Code

Sonia Bobrik — Tue, 18 Aug 2026 12:35:00 +0000

Most engineers meet cryptocurrency the wrong way around: they clone a Solidity boilerplate, deploy a token to a testnet, and only later ask what problem this technology actually solves. Reversing that order pays off, and a solid primer on what you should know about cryptocurrency is a better first step than any tutorial, because the conceptual foundations — decentralization, cryptographic ownership, consensus — have not changed even as the tooling around them evolved dramatically. If you understand why a distributed ledger exists, the code you write on top of it becomes far easier to reason about, audit, and defend.

The Mental Model: Money as a State Machine

Strip away the hype and a blockchain is a replicated state machine with an unusual trust model. Every full node holds the same append-only log, and the network agrees on the next valid state transition without a central coordinator. For a backend developer, this is both familiar and alien. Familiar, because event sourcing and distributed consensus (Raft, Paxos) are established patterns. Alien, because the participants are assumed to be adversarial, which is why proof-of-work and proof-of-stake exist at all: they make lying about the ledger economically irrational rather than merely difficult.

This adversarial assumption changes how you write software. In a conventional CRUD app, a bug ships a patch. On-chain, a bug in an immutable contract can drain funds permanently. Code is not just logic; it is custody. That single sentence explains most of the engineering culture around audits, formal verification, and multi-signature deployments.

What Developers Consistently Get Wrong

The gap between crypto-curious developers and production-ready ones usually comes down to a handful of misconceptions:

Confusing wallets with accounts. A wallet stores keys, not coins. The "balance" is a derived value computed from ledger history, which is why losing a private key means losing access forever — there is no password-reset endpoint.
Treating gas as a nuisance instead of a design constraint. Fees are the pricing signal of a shared computer. Efficient storage layouts and batched transactions are not micro-optimizations; they are the difference between a usable product and an abandoned one.
Assuming volatility is the whole story. Stablecoins and settlement rails behave very differently from speculative tokens, and conflating them leads to bad architecture decisions.
Ignoring the regulatory layer. Compliance requirements shape token design as much as any technical spec, and pretending otherwise is how promising projects die in legal review.

Each of these mistakes is cheap to fix in a design document and catastrophically expensive to fix after mainnet deployment.

The Business Layer You Cannot Skip

Engineers love to dismiss the "business side," but in this domain the economics are the protocol. Incentive design determines whether validators behave honestly, whether liquidity stays in a pool, and whether users tolerate transaction costs. Researchers at Harvard have documented how digital currencies can reshape payments for small businesses, lowering cross-border settlement costs that traditional rails have kept artificially high for decades. That is the actual product story: not price charts, but cheaper, faster, programmable movement of value. A developer who can articulate that story writes better requirements, asks sharper questions in sprint planning, and builds features people genuinely need.

It also helps to be honest about trade-offs. Decentralization costs throughput. Immutability costs flexibility. Transparency costs privacy. Great crypto engineering is the art of choosing which of those costs your specific use case can afford — a payments app, an identity system, and a game economy will land in three different places on that spectrum, and no single chain is optimal for all of them.

A Practical Learning Path That Actually Works

Start with primary sources instead of influencer threads. Read the Bitcoin whitepaper (nine pages, remarkably readable), then work through a reference explainer such as Investopedia's guide to how cryptocurrency functions as an asset and a technology, which grounds the vocabulary you will encounter in every spec and audit report afterward. Next, run a local node and watch real transactions propagate; nothing demystifies consensus like observing it in your own terminal. Only then move to smart-contract development, and treat your first deployments as disposable experiments, not products.

Finally, build something small that touches real constraints: a faucet with rate limiting, a gas-cost dashboard, a script that verifies Merkle proofs. Toy projects that interact with live network conditions teach more than any course, because they force you to handle reorgs, nonce management, and fee spikes — the unglamorous details that separate demos from software.

The technology will keep mutating. The fundamentals in this article will not. Learn them once, properly, and every future framework becomes just another syntax on top of ideas you already own.

You Shipped the Product and Closed the Round. Now Comes the Part Nobody Prepared You For

Sonia Bobrik — Tue, 18 Aug 2026 12:33:18 +0000

There is a strange silence that settles over a startup the week after a funding announcement. The wire transfer clears, the congratulatory messages slow down, and suddenly the metric that matters is no longer "can we raise" but "will anyone believe us." Most technical founders discover this the hard way, which is why the argument laid out in this breakdown of why PR is your next strategic move after securing funding deserves more attention from engineering-led teams than it typically gets. Capital buys you runway; it does not buy you credibility. And credibility, not code, is usually the bottleneck between a funded startup and its first hundred paying customers.

Why Engineers Underestimate the Trust Problem

If you come from a software background, you are trained to believe that quality is self-evident. Good code passes tests. Fast APIs benchmark well. The product either works or it doesn't. Trust feels like something that should emerge automatically from technical excellence.

The market does not work that way. A prospective enterprise customer evaluating your API cannot read your codebase. An early hire weighing your offer against a FAANG salary cannot inspect your cap table. A journalist deciding whether your launch is worth covering has forty other pitches in their inbox. Every one of these people is making a decision under uncertainty, and under uncertainty, humans default to social proof: who else vouches for you, who has written about you, and whether your public footprint matches your private claims.

This is not a soft-skills platitude — it is measurable. The 2026 Edelman Trust Barometer, which surveyed nearly 34,000 people across 28 countries, found that people have retreated into narrow, insular circles of trust and are openly hesitant to extend confidence to anyone unfamiliar. For a startup, "unfamiliar" is your default state. You are asking skeptical strangers to bet their money, careers, or reputations on a company they learned about last Tuesday. The data says they won't — unless you give them independent reasons to.

Trust Is an Engineering Problem With Known Components

The good news for systematic thinkers: trust decomposes. Harvard Business School professor Frances Frei and her co-author Anne Morriss argue in their widely cited framework, Begin with Trust, that trust rests on three drivers — authenticity, logic, and empathy — and that when trust breaks, it is almost always because one specific driver "wobbles." That framing turns a fuzzy concept into something you can debug.

Applied to a freshly funded startup, the three drivers translate into concrete workstreams:

Logic means your public claims are verifiable. Publish real benchmarks, honest changelogs, and postmortems when things break. Nothing destroys credibility faster than a landing page that promises magic and a product that ships excuses.
Authenticity means the founders are visible as actual humans. Technical blog posts, conference talks, and candid interviews about what you got wrong outperform polished corporate messaging, especially with developer audiences who have finely tuned marketing detectors.
Empathy means communicating in your audience's language about their problems. A security-conscious CTO cares about your SOC 2 timeline, not your Series A party. Coverage and content that address the reader's risk, not your ego, build durable goodwill.

Notice that none of this requires a massive budget. It requires the same discipline you already apply to shipping software: consistent output, honest error handling, and iteration based on feedback.

The Compounding Effect Most Founders Miss

Here is where post-funding communications stops being a vanity exercise and starts behaving like infrastructure. Every credible third-party mention — a feature in a respected outlet, a founder quote in an industry analysis, a well-received technical deep dive — becomes a permanent asset. Sales teams attach it to outbound emails. Recruiters cite it in offer conversations. Future investors find it during diligence. Unlike a paid ad, which stops working the moment you stop paying, earned credibility compounds quietly in the background of every deal you pursue for years.

There is also a defensive dimension. At some point your startup will hit turbulence: an outage, a layoff, a pricing change that angers users. Companies with an established, honest public voice get the benefit of the doubt. Companies that only ever communicated through press releases get roasted on Hacker News. The reputation you build in calm weather is the only thing that protects you in a storm, and it cannot be manufactured retroactively.

A Practical Starting Point

If you are a founder staring at fresh capital and wondering where communications fits in your roadmap, treat it like any other system: start small, instrument it, and iterate. Pick one channel where your actual buyers spend time and commit to a sustainable cadence — one substantive engineering post a month beats a burst of five followed by a year of silence. Write down the three claims about your company you most need strangers to believe, then audit whether any independent source currently supports them. Wherever the answer is no, you have found your first project.

Funding proves that a handful of investors believed your story. Trust is what happens when everyone else does. The teams that treat it as a first-class deliverable — planned, shipped, and maintained like production code — are the ones still standing when the runway from that celebrated round finally runs out.

Why Due Diligence Is Becoming the Most Underrated Skill in Tech

Sonia Bobrik — Sun, 09 Aug 2026 13:49:30 +0000

Every week, engineering teams adopt new frameworks, sign off on vendor integrations, and greenlight AI tools that will quietly shape their products for years — often after nothing more rigorous than a quick demo and a gut feeling. A recent conversation on becoming the new due diligence layer for innovation captures a shift many of us have felt but rarely named: in a world where anyone can ship something that looks impressive in a weekend, the ability to verify what actually works has become more valuable than the ability to build. Due diligence is no longer a back-office ritual for lawyers and investors. It is becoming a core engineering discipline — and the developers who master it are quietly becoming the most trusted people in the room.

The Demo Is No Longer Evidence

For most of software history, a working demo was a reasonable proxy for competence. If someone could show you a functioning product, they had almost certainly done serious engineering to get there. That signal is now broken. AI-assisted development means a polished prototype can be assembled in hours, complete with a landing page, documentation, and confident marketing claims. The gap between "looks finished" and "is finished" has never been wider.

This is why verification is eating the software conversation. When output is cheap, scrutiny becomes the scarce resource. The teams that thrive are not the ones that adopt the most tools — they are the ones that can quickly and reliably answer three questions: Does this actually do what it claims? What breaks under load? What will this cost us in two years?

What Investors Figured Out Before Engineers Did

The venture capital world institutionalized this mindset decades ago. In a landmark survey of nearly 900 firms, researchers writing for Harvard Business Review found that the average fund screens around 200 companies a year and invests in only four — a filtering ratio that makes even the pickiest code reviewer look permissive. Their findings on how venture capitalists make decisions reveal something instructive: experienced investors weight the team more heavily than the product, because products can be rebuilt but judgment cannot. The same logic applies when you evaluate an open-source dependency. The code you see today matters less than the maintainers behind it, their responsiveness to security issues, and the health of the community that will carry the project forward.

The Hidden Liability Nobody Prices In

The single most expensive thing due diligence uncovers is rarely a bug. It is accumulated technical debt — the invisible mortgage attached to every system that was built fast and cleaned up never. McKinsey's research on tech debt and how to reclaim tech equity found that CIOs estimate this debt at 20 to 40 percent of the value of their entire technology estate, with 10 to 20 percent of new-product budgets silently diverted to servicing it. Read that again: up to a fifth of the money meant for innovation is being taxed by yesterday's shortcuts.

When you evaluate a vendor, an acquisition target, or even a codebase you are about to inherit, this is the number that matters most — and it never appears in the pitch deck. A skilled due diligence practitioner learns to estimate it anyway, from clues like deployment frequency, test coverage trends, dependency freshness, and how long the team takes to answer a simple technical question.

A Practical Framework You Can Use Tomorrow

You do not need an M&A budget to run meaningful diligence. Before your next significant adoption decision, work through these checks:

Trace the claim to the mechanism. For every headline feature, ask how it works. Vague answers about "proprietary AI" or "advanced algorithms" are a signal, not an explanation.
Stress the edges, not the center. Demos are optimized for the happy path. Feed the system malformed input, concurrent requests, and your ugliest real-world data.
Audit the humans. Check commit history, issue response times, and turnover. A brilliant tool maintained by one exhausted person is a risk, not an asset.
Model the exit before the entrance. Estimate what migrating away would cost. If the answer is "we couldn't," you are not buying a tool — you are accepting a dependency.
Verify independently. Talk to actual users outside the vendor's reference list. Five minutes with a disillusioned customer is worth fifty pages of documentation.

The Career Angle Nobody Is Talking About

Here is the uncomfortable truth for developers worried about AI commoditizing their work: writing code was never the hard part, and it is about to become even less so. The durable skill is judgment — the ability to look at something new, ask the questions that expose its real shape, and take responsibility for the answer. Every organization is drowning in options and starving for verification. The engineer who can say "I checked, and here is what I found" with genuine rigor behind it is not competing with autocomplete.

Due diligence is not glamorous. It produces no launch tweets and no conference talks. But it is rapidly becoming the layer that separates organizations that compound value from organizations that compound regret. Learn to be that layer, and you will never be the person a team can afford to lose.

The Most Dangerous Endpoint Is the One Nobody Remembers Owning

Sonia Bobrik — Sun, 09 Aug 2026 13:48:56 +0000

Somewhere on the internet, an application built for a temporary event is still answering requests years after everyone involved has moved on. One surprisingly good illustration is a Bowdoin Reunion ride board from 2013, where the surrounding event belongs to another era of the web while the discussion surface has continued to host much newer activity. The interesting part is not that an old page survived. The interesting part is that software can outlive its purpose without outliving its capabilities.

Developers are trained to think about software in terms of what exists in the current product: the routes in the current repository, the services visible in the current architecture diagram, the APIs documented in the current OpenAPI specification.

The internet does not care about any of those boundaries.

If an endpoint still answers, it exists.

If a form can still submit, it exists.

If an old API version can still reach production data, it exists.

If an abandoned subdomain still resolves to infrastructure, it exists.

And if your engineering team has forgotten it exists, an external observer may understand that part of your system better than you do.

That is the uncomfortable engineering problem behind what we can call zombie functionality: features that are dead organizationally but alive technically.

“Nobody Uses It” Is Not a System State

Teams use surprisingly imprecise language when software gets old.

“We don't use that anymore.”

“That was for the old site.”

“I think marketing stopped using it.”

“That API was replaced two years ago.”

“That admin panel belongs to the previous platform.”

None of these statements tells us what the computer will do when someone sends it a request.

There is a huge difference between deprecated, hidden, unlinked, unsupported, read-only, access-restricted, and actually removed. Inside a company, those states can feel roughly equivalent because employees no longer encounter the feature in normal workflows. From outside the company, they are completely different.

Removing a navigation link does not remove a route.

Deleting the frontend button does not disable the backend operation.

Launching /api/v3/ does not automatically kill /api/v1/.

Moving employees to a new admin portal does not make the previous portal unreachable.

This distinction sounds obvious when written down. In real systems, it is repeatedly missed because product retirement is usually treated as an organizational decision rather than a technical lifecycle.

A feature gets a launch process.

It rarely gets a death process.

Software Has an Afterlife

Modern software development optimizes aggressively for creation.

We have templates for starting services, infrastructure-as-code for provisioning resources, CI/CD pipelines for shipping builds, feature flags for activating functionality, observability for watching it, and dashboards for measuring adoption.

There is much less infrastructure for proving that something is gone.

Imagine an internal tool launched in 2020.

The first version lives at admin.example.com.

In 2022, the company rebuilds it at console.example.com.

Everyone migrates. Documentation is updated. The old link disappears from Notion. A year later, half the engineers who built the first version have left.

What happened to admin.example.com?

Maybe the DNS record still exists.

Maybe a load balancer still knows where to send the request.

Maybe the old application still authenticates against the same identity provider.

Maybe the application uses an old authorization model.

Maybe it shares a database with the new console.

Or maybe it returns a 404.

The important point is that you cannot infer its technical state from its organizational state.

This is why forgotten functionality is such an interesting class of engineering debt. Ordinary technical debt is visible because engineers encounter it while changing the system. Zombie functionality can become less visible precisely because nobody changes it.

Its lack of activity protects it from attention.

Attack Surface Is an Inventory Problem Before It Is a Vulnerability Problem

Security discussions often begin with vulnerabilities: outdated dependencies, injection, broken authorization, leaked credentials.

But before you can secure an asset, you have to know that you have it.

That sounds trivial until an organization has accumulated acquisitions, cloud accounts, test environments, regional deployments, SaaS integrations, old domains, contractor-built applications, temporary campaign sites, preview environments, versioned APIs, migration infrastructure, and years of DNS history.

A useful way to understand the problem comes from Google Cloud’s explanation of external attack surface management, which focuses on continuously discovering internet-facing assets rather than assuming the internal inventory is complete.

That word — discovering — matters.

Traditional asset management asks:

“What systems do we own?”

External discovery asks:

“What systems can somebody on the internet find that appear to belong to us?”

Those datasets should be identical.

In a mature organization, they often are not.

And the difference between them is where some of the most interesting risks live.

The Frontend Can Die While the Capability Survives

One reason zombie functionality is easy to create is that users experience products through interfaces, while systems expose capabilities through layers.

Suppose a company has a profile page with a “Delete account” button.

Later, the UI is redesigned and the button moves into a new settings application. The previous settings page is removed from the router.

From the product team's perspective, the old feature is gone.

But perhaps the original request was:

POST /legacy/account/delete?id=1234

If that handler still exists, the capability has not disappeared. Only one path humans used to discover it has disappeared.

This distinction becomes especially important with APIs because APIs are designed to be called directly. They do not need a visible button.

A deprecated mobile application may therefore leave behind an API generation long after the application itself has vanished from app stores.

A retired integration may leave behind OAuth scopes.

A discontinued partner program may leave callback handlers.

A removed upload screen may leave the upload endpoint.

A beta feature may leave database fields, jobs, queues, permissions, and routes long after the feature flag is turned off.

What users see as one feature may correspond to dozens of independently surviving technical artifacts.

Deleting the visible part is easy.

Proving that the capability has disappeared is harder.

The Real Problem Is Ownership Decay

Code does not literally become more dangerous because it is old.

Ownership decays.

The engineer who understood why an endpoint bypasses the normal service layer leaves.

The team that operated a microsite is dissolved.

The vendor that built the original portal is replaced.

A cloud subscription moves between departments.

A database gets inherited by another application.

The source repository is archived.

Monitoring is pointed at the new system.

The old system continues answering requests.

Eventually you reach a strange condition: the company still owns the software, but nobody meaningfully owns its behavior.

This is more serious than missing documentation.

Ownership determines who receives alerts, approves dependency upgrades, understands data flows, responds to incidents, evaluates changes in authentication requirements, and makes the decision to finally shut something down.

Without an owner, “temporary” infrastructure has a remarkable tendency to become permanent.

The Internet Has Better Memory Than Your Org Chart

There is another asymmetry developers should understand.

Internal knowledge disappears when people leave and systems change.

External evidence often remains.

Certificate Transparency logs can reveal historical hostnames. Search engines remember paths. Old JavaScript bundles contain API routes. Public Git repositories preserve configuration history. Documentation forks survive after official docs are rewritten. Browser extensions and mobile binaries can preserve references to servers long after those products stop being maintained.

This means removing something from your current architecture diagram does not necessarily make it undiscoverable.

Attack-surface discovery tools work from exactly this assumption. Cloudflare’s discussion of attack surface intelligence describes outside-in discovery of assets such as forgotten subdomains and unmanaged infrastructure — things an internal security workflow can miss because nobody remembered to put them into the inventory in the first place.

There is an important engineering lesson here:

Documentation describes what your organization believes exists. The network reveals what actually exists.

Those are not always the same system.

Deprecation Should Be a State Machine

One reason software retirement goes badly is that “deprecated” is treated as a label.

It should be a sequence of technical states.

A feature should move from something like ACTIVE to DEPRECATED, then perhaps READ_ONLY, then DISCONNECTED, and finally REMOVED.

Each transition should have observable consequences.

When an API becomes deprecated, new consumers should no longer be allowed to register against it.

When it becomes read-only, mutating methods should stop succeeding.

When it is disconnected, application traffic should no longer reach sensitive downstream systems.

When it is removed, infrastructure should disappear rather than merely stop appearing in documentation.

Most importantly, the transition should have an owner and an expiry date.

“Deprecated indefinitely” is another way of saying “production forever.”

Build the Exit Before You Launch

Developers usually think about decommissioning when they are already trying to decommission something.

That is too late.

The easiest system to retire is one designed with retirement in mind.

If you are building a temporary microsite, decide at launch what happens to it after the campaign.

If you are introducing /v2/, decide when /v1/ loses write access.

If you create a preview environment, decide what deletes it.

If you launch a feature flag, decide whether disabling it removes only UI exposure or also backend capability.

If you provision a new public hostname, give it an owner at creation time.

A useful production lifecycle check can be surprisingly compact:

What publicly reachable asset is being created?
Who owns it after the original project ends?
What sensitive systems or data can it reach?
How will we know whether legitimate traffic still depends on it?
What exact event moves it into retirement?
What proves that retirement actually completed?
What prevents the same asset from silently reappearing during a rollback or old deployment?

The point is not to create more paperwork.

The point is to make deletion as real an engineering operation as deployment.

Start Measuring Negative Space

Most engineering metrics measure things that are happening.

Requests per second.

Error rate.

Latency.

CPU.

Active users.

Deploy frequency.

Conversion.

Zombie systems often require the opposite question:

What is still reachable even though almost nothing legitimate should be happening there?

That makes low traffic interesting.

Imagine an endpoint that normally receives five requests per month.

Traditional monitoring may consider it irrelevant.

But if the product containing that endpoint was retired two years ago, five requests are not “low usage.” They are unexplained usage.

The baseline should be zero.

The same applies to old domains, deprecated APIs, retired OAuth clients, stale service accounts, abandoned queues, and forgotten cloud functions.

Engineering organizations are good at detecting unexpected increases.

They should become equally good at detecting unexpected survival.

Do Not Confuse a 404 With Decommissioning

Even apparently dead systems can remain alive underneath.

A reverse proxy can return a 404 while the original application continues running behind it.

A firewall rule can block public access while an obsolete service retains broad internal network access.

A DNS record can be removed while cloud resources continue accumulating cost and credentials remain valid.

A frontend deployment can disappear while storage buckets and serverless functions survive.

Real decommissioning therefore requires working backward through dependencies.

What identity can access the system?

What identities can the system access?

What databases does it know about?

What secrets does it hold?

What queues does it consume?

What webhooks point to it?

What scheduled jobs invoke it?

What DNS records reference it?

What certificates were issued for it?

What logs would prove that something still depends on it?

This is essentially garbage collection for infrastructure, except reference counting is much harder because many references live outside the system you control.

Temporary Software Is Often the Least Temporary Software

Some of the strangest long-lived systems begin as short-term projects.

Conference registration sites.

University event boards.

Marketing campaigns.

Election dashboards.

COVID-era portals.

Hackathon applications.

Product betas.

Migration bridges.

Emergency internal tools.

Temporary systems are often built under deadline pressure, with weaker ownership structures and an assumption that somebody will remove them later.

Then they work.

And because they work, nobody wants to touch them.

The project ends, priorities change, the original team moves on, and “remove old site” loses every roadmap battle against new revenue-generating work.

Ironically, the feature nobody expected to survive ten years may receive less lifecycle engineering than the platform explicitly designed to survive ten years.

That is how temporary becomes permanent.

The Best Security Improvement May Be Subtraction

Software engineering has a strong bias toward adding controls.

Add authentication.

Add a WAF.

Add monitoring.

Add another scanner.

Add another policy.

Sometimes the cleanest control is to remove the capability entirely.

An endpoint that does not exist needs no patch.

A deleted cloud account needs no monitoring.

A removed API version needs no authorization policy.

A retired admin interface cannot accidentally retain yesterday's permissions.

A destroyed credential cannot leak next year.

This is one of the rare areas where maintainability, cost, architecture, and security all point in the same direction.

Smaller systems are easier to understand because there are fewer truths to keep synchronized.

The challenge is that subtraction requires certainty. Teams hesitate to delete old systems because they do not know what depends on them.

Which brings us back to inventory.

You cannot confidently remove what you cannot confidently map.

Every Deployment Creates a Future Legacy System

Developers rarely think of the service they are launching today as legacy software.

But unless it fails immediately, that is exactly what it is becoming.

Frameworks will change.

Teams will change.

Authentication systems will change.

Domains will be reorganized.

APIs will be replaced.

Infrastructure providers will come and go.

The question is not whether today's architecture becomes old.

The question is whether the organization retains enough control over its lifecycle to know when old software is still doing real work.

The most important mental shift is simple:

Production is not the set of systems your team currently works on. Production is the set of systems that can still do something.

Once you use that definition, neglected endpoints stop being digital archaeology.

They become current architecture.

And perhaps the most valuable question in your next architecture review is not “What are we building?”

It is:

What is still running that nobody in this room remembers building?

Why Reputation Behaves Like a Financial Variable

Sonia Bobrik — Sun, 09 Aug 2026 13:48:08 +0000

Every engineer knows that technical debt eventually shows up in the release schedule, yet few founders realize that reputational debt shows up somewhere far more painful — the income statement. The idea that reputation is a financial variable rather than a soft PR concept changes how you should think about everything from your changelog to your incident reports, because trust quietly rewrites three numbers investors care about most: cash flow, risk premium, and terminal valuation. If you build products, you are already building (or burning) this asset every single sprint, whether you track it or not.

The Mechanics: How Trust Moves Cash

Think of reputation as a discount applied to friction. A trusted company closes deals with shorter sales cycles, negotiates better payment terms, and retains customers without bribing them with promotions. An untrusted company pays for the same outcomes in cash — bigger marketing budgets, deeper discounts, longer legal reviews, higher churn. The revenue line might look similar for a while, but the cost structure diverges dramatically.

This is why acquirers routinely pay far more than the book value of a target's tangible assets. Accountants have a name for that premium: as the classic explainer on goodwill in accounting makes clear, brand strength, customer loyalty, and reputation are literally capitalized onto the balance sheet the moment a transaction forces the market to name their price. Until that moment, the asset is invisible — but it was always there, compounding or decaying.

For a developer-founder, the practical translation is simple. Every public postmortem you write honestly, every breaking change you document properly, every security disclosure you handle transparently is a deposit. Every silent outage, every dark-pattern upsell, every quietly deprecated API is a withdrawal — with interest.

Risk: The Multiplier Nobody Budgets For

Cash flow is only half the equation. The other half is the rate at which future cash flows get discounted, and that rate is a direct function of perceived risk. Two companies with identical revenue can carry wildly different valuations because one of them is considered fragile.

Reputation acts as an insurance policy here. When a trusted company stumbles — a data incident, a bad quarter, a botched launch — stakeholders extend the benefit of the doubt. Customers wait for the fix instead of migrating. Journalists frame it as an anomaly. Investors hold. When a distrusted company makes the identical mistake, the same event triggers cancellations, coverage pile-ons, and margin calls. The mistake is constant; the damage function is not.

Harvard Business School's Frances Frei has argued persuasively that this dynamic starts inside the organization: her framework on why leaders must begin with trust breaks credibility down into authenticity, logic, and empathy — and shows that when any one leg wobbles, everything built on top of it wobbles too. External reputation is largely internal trust made visible; teams that don't trust their leadership eventually ship products users can feel that distrust through.

What This Means for People Who Ship Software

You don't need a CFO to act on this. You need to treat trust signals as engineering artifacts with the same rigor you apply to test coverage. Concretely, the highest-leverage moves are:

Publish honest postmortems. A blameless, detailed incident writeup converts a failure into proof of competence. Silence converts it into a rumor.
Version and deprecate predictably. Nothing erodes developer trust faster than surprise breaking changes. A boring, well-communicated deprecation policy is a valuation asset.
Make pricing and data practices legible. If users need a lawyer to understand what you do with their data, you are accruing reputational debt at a compounding rate.
Respond to security reports fast and gratefully. How you treat the researcher who found your vulnerability is public information within hours.

Notice that none of these items is expensive. They are disciplines, not budgets — which is exactly why they are underinvested. Costs that don't appear on any dashboard get deferred, and reputational maintenance is the ultimate invisible cost until the day it becomes the only visible one.

The Compounding Curve

The most counterintuitive property of reputation-as-capital is its asymmetry. Building it is linear and slow: one honest release note, one kept promise, one transparent quarter at a time. Destroying it is exponential and fast: a single incident handled badly can vaporize years of deposits in a weekend, because trust violations propagate through networks far faster than trust confirmations do.

This asymmetry is not a reason for paranoia; it's a reason for process. Companies that survive crises are rarely the ones that never make mistakes — they are the ones whose reserve of accumulated credibility was deep enough to absorb the drawdown. In financial terms, they held a buffer against reputational volatility, the same way a prudent treasury holds a cash buffer against operational volatility.

So the next time someone on your team dismisses transparency as "just optics," reframe it in the only language every stakeholder understands: reputation is working capital. It lowers your cost of everything, cushions your downside, and gets priced — eventually, always — into what your work is worth.

A Developer's Guide to Financial Friction

Sonia Bobrik — Sun, 09 Aug 2026 13:47:27 +0000

Every engineer who has ever wired up a checkout flow knows the quiet dread of watching conversion metrics after deploy day. A single extra form field, a redirect to a bank page, a 3-second delay on card authorization — each one bleeds users. What fewer developers realize is that these micro-frustrations have macro consequences, and a growing body of analysis, including a sharp breakdown of why financial friction is reshaping competitive dynamics across entire industries, suggests that friction is no longer just a UX problem. It is a strategic weapon, a moat, and — depending on which side of the API you sit on — either your biggest opportunity or your slowest-acting existential threat.

What Friction Actually Costs

In economics, friction is anything that makes an exchange harder than it needs to be: fees, delays, paperwork, uncertainty. Economists have studied this for decades under the umbrella of transaction costs, the invisible tax that every intermediary, verification step, and settlement window adds to a deal. For most of the twentieth century, these costs were treated as fixed features of the landscape. Banks settled when banks settled. Cross-border transfers took five days because that was simply how correspondent banking worked.

Software changed the equation. Once payments became programmable, friction became a variable — something a product team could measure, reduce, or deliberately preserve. And that is exactly where competition got interesting.

Friction as a Competitive Lever

Consider two companies selling identical products at identical prices. Company A requires account creation, a billing form, and an email confirmation. Company B offers one-tap purchase with stored credentials. Over a quarter, Company B does not just convert better — it accumulates behavioral data, repeat purchases, and habit formation that compound into a durable advantage. The product never changed. The friction did.

This is why incumbents and challengers now fight over milliseconds and form fields rather than features. The pattern echoes what Michael Porter and James Heppelmann described in their landmark analysis of how smart, connected products are transforming competition: when the connective tissue of an industry becomes digital, the basis of rivalry shifts from what you sell to how seamlessly you deliver it. Payments are the connective tissue of everything, which makes financial friction the most universal battleground in modern software.

Where Developers Feel It Most

If you build products for a living, financial friction shows up in your work in concrete, recurring ways:

Checkout abandonment, where every additional second of latency or every extra input field measurably reduces completed purchases
Onboarding drop-off in fintech, where KYC and identity verification steps are legally required but brutally punishing to activation rates
Marketplace liquidity, where slow seller payouts push suppliers toward platforms that settle faster
Subscription churn, where failed card retries and involuntary cancellations quietly erode recurring revenue
Cross-border expansion, where currency conversion costs and settlement delays decide which markets are even viable

None of these are traditionally "engineering problems," yet engineers are the ones who solve them — through smarter retry logic, tokenized credentials, asynchronous verification, webhook-driven payout systems, and payment orchestration layers that route transactions to whichever processor clears fastest and cheapest.

The Strategic Paradox: Sometimes Friction Is the Product

Here is the counterintuitive part. Not all friction is bad, and removing it indiscriminately can destroy value. Fraud prevention is friction. Two-factor authentication is friction. Cooling-off periods before large transfers are friction — and they save users from irreversible mistakes. The companies winning right now are not the ones with zero friction; they are the ones with precisely placed friction. They make the happy path effortless and reserve resistance for the moments where risk genuinely lives.

This is a design philosophy as much as a technical one. A well-architected payment system behaves like a good type system: invisible when you are doing the right thing, loud exactly when you are about to do the wrong thing.

What This Means for Your Roadmap

If you are building or maintaining anything that touches money, three practical shifts are worth making. First, instrument friction the way you instrument errors — measure time-to-complete, step abandonment, and retry rates as first-class metrics, not afterthoughts. Second, treat your payment stack as a product surface, not plumbing; the difference between a 1.5% and a 2.1% authorization failure rate is a competitor's entire growth budget. Third, watch the regulatory horizon. Open banking mandates, instant payment rails, and real-time settlement systems are dismantling old frictions faster than most incumbents can adapt, and every dismantled friction reshuffles who wins.

The uncomfortable truth is that the smoothest experience in your market sets the expectation for everyone else. Users do not compare your checkout to your direct competitor's checkout — they compare it to the best checkout they used anywhere, yesterday. In a world where friction is programmable, the teams that treat it as a strategic variable rather than an inherited constant will be the ones still shipping five years from now.