The framing effect presents cognitive bias in which people’s decisions change not because the facts change but because the presentation of those facts changes [1]. The very same information can trigger entirely different reactions depending on whether it is framed as a potential gain or a potential loss. Although the underlying outcome remains objectively identical, our perception of its value shifts with the wording, context and emotional tone used to describe it. When attention is drawn to what can be won, options tend to feel safer and more attractive, when emphasis is placed on what could be lost, the very same choices suddenly appear risky or threatening.

Framing bias in business occurs when decisions change based on how information is presented rather than the underlying facts. Leaders may choose different strategies depending on whether outcomes are framed as gains or losses. Recognizing this bias helps improve strategic thinking, reduce emotional influence, and support more consistent, evidence-based decision-making.

Image 2 Same facts – different decisions

Source: https://rebelsguidetopm.com/the-impact-of-framing-in-decision-making/

We like to think we’re rational, but countless studies show that the words and context used to frame a decision can steer our choices. Business leaders can be just as vulnerable to framing, especially in high-pressure scenarios:

• Strategic decisions – Gain vs. Loss Framing: imagine a company crisis with two restructuring plans: Plan A will “save 200 jobs” out of 600, whereas Plan B has a risky chance to save all or none. Alternatively, describe Plan A as “400 jobs will be lost” out of 600 (the same scenario phrased in terms of losses). Experiments show dramatically different group preferences between these framings. When phrased as lives or jobs saved (a gain frame), decision-makers tend to become risk-averse and favor the sure-save option (Plan A). But when the identical outcome is phrased as lives or jobs lost (a loss frame), people become risk-seeking, often preferring the gambit of Plan B to avoid a certain loss. In real companies, executives may greenlight a project when it’s pitched as “95% chance of success” but reject the same project described as “5% chance of failure.” The content is the same, the emotional impact is not.
• Marketing and customer perception: framing is a well-known tool in marketing. A product labeled “90% fat-free” is more appealing than one stating “contains 10% fat” though they’re identical. Likewise, customers react differently to a fee described as a “small $5 fee” vs. a “5% surcharge”, the way the cost is framed influences their behavior without changing the facts. In one illustration, consumers said they’d rather buy disinfectant wipes “that kill 95% of germs” than wipes where “5% of germs survive” even though 95% efficacy means exactly 5% survive. In a medical context, patients are more willing to undergo a surgery with “90% survival rate” than one with “10% mortality rate”, despite them being the same odds. In each case, framing changes the perceived risk or benefit.
• Employee communications and policy: how management proposals are framed to employees can sway buy-in. For instance, announcing a new policy as “ensuring 99% uptime” will land better than saying it “allows up to 1% downtime”. A cost-cutting initiative framed as “securing our financial health” may gain more support than one framed as “we must reduce budgets by 10%,” which sounds like a loss. Leaders often inadvertently bias the response by the frame they choose to emphasize.

Framing works by tapping into our emotional and psychological reference points, we typically fear losses more than we value equivalent gains (“loss aversion”), so a negative frame hits harder. We also take mental shortcuts based on wording: certain words trigger positive or negative associations that influence judgment beyond the raw data.

Escaping the Framing trap

Escaping the trap begins with one disciplined habit, learning to spot the frame before we accept the picture it paints. As workshop takeaway put it, knowing about the framing effect makes us more vigilant decision-makers. Beyond awareness, the practical technique is reframing:

• Deliberately rephrase the problem: whenever you’re given information or a choice, try to state it in the opposite way and see if your preference changes. If an option is presented in positive terms (gains), reframe it in terms of what you stand to lose, and vice versa. Ask, “If this were described in the opposite (positive vs. negative) way, would I still make the same choice?”. This mental exercise forces you to evaluate the substance of the decision rather than the spin.
• Seek neutral wording and objective data: when possible, look for descriptions that avoid loaded terms. In internal discussions, try to ensure that proposals are described in multiple ways, for example, both the upside and downside perspectives. Rather than relying on “90% chance of success” also consider “10% chance of failure” in your risk analysis, so both frames are acknowledged. If you find your reaction differs, dig into why.
• Use structured decision criteria: create a decision matrix or list of factors that doesn’t rely on any single phrasing. This can anchor the team on facts. For instance, in the layoff scenario, list out the expected outcomes of each plan in raw numbers (e.g. “200 jobs remain, 400 cut” for Plan A) without value-laden words like “save” or “loss” to see the equivalence.

Ultimately, guarding against framing bias means building the habit of looking at decisions from multiple angles. By “flipping the frame” and considering alternate presentations, you immunize yourself against being unduly influenced by marketing spin, clever wording or one-sided storytelling. This leads to choices based on core facts and values, not on cosmetic semantics.

Conclusion: building a bias-aware culture for smarter organizations

Cognitive biases are an ever-present part of human decision-making, but they need not derail your business. By shining a light on anchoring, survivorship, availability and framing biases (that were covered in this two part series article), leaders send a clear message: we won’t make decisions on autopilot. They turn to challenging assumptions, seek out what they are not seeing and make the invisible visible. Organizations that embrace this bias-aware approach build a culture of curiosity and continuous learning, one where tough questions are welcomed and decisions are based on reality, not rosy stories or gut feel alone.

By implementing the practices discussed (and continuously updating them as we learn), you lay the foundation for what one might call “decision-making excellence”. In such a culture, big choices are not hurried reactions but well-calibrated moves that combine the best of human intuition with rigorous analysis. Biases will never vanish completely but their influence will be markedly tamed.

As you lead your teams forward, remember: the goal isn’t to eliminate the human element from decisions, but to eliminate the blindfolds. By being aware of what you don’t see and actively seeking it, you empower your organization to make choices that are not just faster or cheaper, but genuinely wiser and that is the ultimate driver of sustained business advantage.

[1] “Framing Effect,” The Decision Lab, 2025. [Online]. Available: https://thedecisionlab.com/biases/framing-effect. [Accessed: Jun. 6, 2026].

If you haven’t read part 3 of this series, be sure to check it out here:

Availability Bias in Business: Why Urgency Is Often an Illusion

The post The framing effect in business decision making appeared first on Pontis Technology.

Every “AI productivity stack” post reads the same. A tool grid. No glue.

Here’s mine, organized by the workflows they live inside, not the categories they belong to. Plus the honest answer for Windows and Linux people, because half of you aren’t on macOS.

(Reading on mobile? Skip to the matrix at the bottom. That’s the useful part.)

What Is an AI Productivity Stack?

An AI productivity stack is the collection of AI tools, workflows, and integrations that help knowledge workers, developers, and teams capture information, make decisions, build software, manage knowledge, and automate repetitive work. The most effective AI productivity stacks are organized around workflows rather than individual tools

Why most “my stack” posts miss

Tool lists are the fast food of LinkedIn. Filling, forgettable by lunch, calories from the wrong places.

A tool on its own doesn’t really do anything. A tool inside a ritual does. So, this post is organized around the five loops I actually run, and the tools fall out of the ritual naturally.

One caveat before we dive in. I work on a Mac. Most of my stack is cross-platform. Some of it isn’t. I’ve added platform notes next to each tool, and there’s a proper Mac/Windows/Linux matrix at the end.

Loop 1, capture

The goal here is simple. Lower the cost of getting a thought, a meeting, or a decision out of my head and onto a searchable surface.

Wispr Flow for voice dictation. It runs on Mac, Windows, iOS, and Android. I use it in every text field on the OS, not just documents. Typing feels archaic now. If you’re on Linux, Whisper via Whishper or WhisperX gets you close, though it’s rougher around the edges.

 Fathom for meetings. Free unlimited recording, supports Zoom, Meet, and Teams. In April 2026 they shipped a botless mode, which finally kills the “there’s a third participant on this call” awkwardness. I moved off ChatGPT Record for recurring meetings because running two sources of truth was costing me more time than it saved.

ChatGPT Desktop stays in the mix for one-off recordings when I’m the only one in the room. Workshops, whiteboard sessions, a long walk where I want the thinking transcribed.

Rule of thumb: capture has to be frictionless. If it takes more than one shortcut, the friction compounds across a day, and I stop capturing.

Loop 2, think

The goal is turning raw capture into decisions, not just more notes.

Claude Desktop is my main chat surface. Mac and Windows, not Linux. The reason I stay here is Claude Cowork, the desktop control mode that can operate native Mac and Windows apps, not just the web. Last mile automation is where most knowledge work actually happens, and web agents can’t see your Finder.

ChatGPT still wins in a few niches. Voice mode on a walk, image edits, the occasional sanity check on what Claude just told me.

Perplexity when the question needs sources more than reasoning. I think of it as: Claude for “help me think”, Perplexity for “tell me what’s out there”.

I dropped Notion AI. Running Claude against my Notion via MCP is cheaper and better. That isn’t a hot take in mid 2026. It’s just the math.

Loop 3, build

This is the part of the stack that gets argued about most on LinkedIn, so I’ll be precise.

Cursor for flow. The autocomplete is still best in class, and when I’m in a tight edit loop it’s faster than talking to an agent.

Claude Code for depth. Anything touching more than a few files, a migration, a refactor I can describe in English. It runs in the terminal (Mac, Windows, Linux) and is more token efficient than you’d expect. This is where Warp earns its seat.

Warp as the terminal. GPU rendered, block based, and the cloud agent orchestration (Oz) means I can hand off long running jobs without a local shell staying open. Mac and Linux today, Windows in alpha.

Codex for code review. I develop with Claude Code, then run a second pass through OpenAI’s Codex app. Having a different model review the code catches things a same model review won’t. I tried CodeRabbit and Cursor BugBot for a while, both are solid products, but the two model loop (Claude writes, GPT reviews) is the one I actually kept running. Cross-platform.

Docker Desktop for local containers and, newly interesting, microVM sandboxes to run agents in isolation. Cross-platform.

DBeaver for databases. Open source universal SQL client, added MCP support this year. Cross-platform, free, zero regrets.

Ollama for local models. I’m not running production workloads on it, but for iteration, running cheap loops before paying for a frontier call, it’s essential. Cross-platform, open source, 52M downloads in Q1 2026 alone.

A contrarian note. Cursor’s pricing got hostile in 2025 (the credit reset was painful for anyone deep in a long session). Claude Code plus Warp is cheaper for most teams now. I still keep Cursor for the autocomplete and because IDE switching costs are real.

Loop 4, know

Make the sum of what I’ve read, written, and decided retrievable in seconds.

Obsidian is my personal RAG. Local markdown, cross-platform, plugin ecosystem that ages well. With Claude connected via MCP, it queries my vault directly. This isn’t a chat interface over my notes. It’s an agent that reads them when it needs context.

Notion is the team’s surface. Docs, wikis, project databases. The split is deliberate: Obsidian for what I’m thinking, Notion for what the team needs to know.

Raycast ties both to the OS. I use it for snippets (prompt templates I reach for weekly), clipboard history, and as a universal launcher. Mac native, Windows in beta. If you’re on Linux, Ulauncher is the closest philosophical cousin.

Loop 5, operate (the daily OS)

The day itself runs on rails, not on willpower.

Raycast opens everything from one keystroke.

LookAway forces breaks. 20 20 20 rule for the eyes, posture reminders, Pomodoro style sessions. Mac only, unfortunately. On Windows I’d look at Stretchly, which is open source and cross-platform. Founders who scoff at break timers burn out fastest. I’ve watched it happen more than once.

Setapp covers the long tail of Mac utilities. CleanShot X for screenshots, LookAway itself, Dato for a better menu bar clock, a dozen more. $12.99/mo for 250+ native apps is a bargain if you live on a Mac.

Docker keeps local dev reproducible across the team.

What I’d add if I were starting today

If I rebuilt the stack from scratch in April 2026, three things I don’t yet have would go in first.

A calendar AI, like Reclaim or Motion. Founders waste enormous hours on scheduling, and this category has the cheapest ROI by a mile.

A meeting to action pipeline. Fathom feeds Notion database, which triggers a Reclaim follow up, which ends as a Linear or Asana task. Glue it with n8n. I’ve built bits of this. It isn’t end to end yet.

An AI native browser, Dia or Comet. Most people underestimate how much of their work lives in a browser. A browser that reads across tabs is the clearest upgrade in the category since Arc.

The cross-platform picture (the part Windows and Linux people actually care about)

I hate when Mac stack posts hand wave this. So here’s the honest table.

macOS only or macOS first: Raycast (Windows beta exists), LookAway, Setapp (the bundle), CleanShot X, Screen Studio, Superwhisper (if you go local dictation).

Cross-platform and happy about it: Wispr Flow, Claude Code, Codex, Cursor, Zed, Obsidian, Logseq, Heptabase, Ollama, LM Studio, Jan, Continue.dev, Aider, Docker, DBeaver, CodeRabbit, Notion, ChatGPT, Claude Desktop, Warp (Linux is good, Windows is alpha).

Windows first, worth knowing: PowerToys (native quasi Raycast), Microsoft Copilot deeply integrated into Office. Underrated for operator workflows.

Linux first: Espanso for text expansion, Ulauncher as the launcher. Aider plus Continue.dev plus Ollama will get you 80% of the Claude and Cursor experience if you stay local first.

Three patterns worth stealing

Instead of a generic “top 10” to wrap, here are the three patterns that reshape how my day actually goes.

Voice to knowledge loop. Wispr Flow, Fathom, Obsidian, Claude via MCP. Capture is voice, retrieval is agentic, and I never “take notes” in the traditional sense anymore.

Multi runtime dev. Ollama locally for cheap iteration, Claude Code for depth, Cursor for flow. “Local vs cloud” is the wrong frame. It’s multi runtime, and each loop picks the right one.

Desktop control as the last mile. Claude Cowork does what web agents can’t. It opens my Finder, drives my Mail, fills forms in native apps. Roughly a third of knowledge work lives in native apps, and automating that is the real unlock.

One thing I’m watching

MCP adoption. Ten thousand public servers, Anthropic’s donation to the Linux Foundation in December 2025, 80% of Fortune 500 deploying agents. Teams whose stack isn’t MCP connected by the end of 2026 will be paying consolidation costs they don’t yet understand. This is the npm of AI agents. You don’t want to show up late.

The post The AI Productivity Stack I Actually Use in 2026 (Tools, Workflows & Cross-Platform Guide) appeared first on Pontis Technology.

Availability bias (also known as the availability heuristic) is a cognitive shortcut that leads people to judge how common, important or likely something is based on how easily they can recall examples of it.

In the context of business decision-making, availability bias causes leaders to overweight information that is recent, vivid, emotionally charged, or highly visible — while underweighting slower-moving, less visible but statistically more important data.

Our brains are naturally wired to prioritise:

• recent events
• emotionally intense stories
• dramatic or high-profile incidents
• highly memorable experiences

As a result, quieter but more statistically meaningful information often fades into the background.

This is why a single viral layoff story can suddenly make an entire industry feel unstable, or one high-profile cyberattack can trigger sweeping security decisions, even if overall risk levels have not meaningfully changed.

What feels most “available” in memory is often mistaken for what is most important in reality.

Availability bias does not distort facts — it distorts attention.

And once attention is distorted, decision-making inevitably follows.

Image 1: Availability heuristic

“If you can think of it, it must be important”

Source: https://statisticsbyjim.com/basics/availability-heuristic/

How availability bias shapes business decision-making

In organisations, availability bias in business decision-making quietly reshapes priorities by shifting focus from structural, long-term signals to recent, highly visible events.

Leaders may overreact to:

• the last complaint they heard
• the most recent headline in the news
• a single vivid anecdote from a key client
• a recent internal incident or failure

As a result, strategic focus moves away from sustainable performance drivers and toward whatever feels most urgent in the moment.

One of the most common expressions of this bias is the tendency to treat the recent past as a reliable guide to the future.

Availability bias leads leaders to overvalue recent, vivid or emotional events, creating false urgency and distorting strategic priorities away from long-term signals.

Recency over trends

When making forecasts, managers often place far more weight on what happened most recently than on long-term patterns.

The latest quarter, last campaign, or most recent crisis feels more “real” than years of historical data — even when the broader dataset is far more representative.

This is a direct expression of availability bias in business decision-making, where cognitive accessibility replaces statistical reasoning.

High-profile events and distorted risk perception

Rare but dramatic events often dominate corporate risk perception far beyond their actual probability.

After a highly public cyberattack or a major competitor failure, executives may behave as if the same event is imminent within their own organisation.

This typically results in:

• sudden budget reallocations
• urgency spikes driven by fear
• overinvestment in visible risks
• underinvestment in less visible but more probable risks

In startups, the same effect appears when one funding success story inflates expectations while hundreds of average outcomes are ignored.

A vivid narrative always feels more convincing than long-term probability data — even when it is statistically irrelevant.

Sharks vs coconuts: a classic availability bias example

A widely cited example of availability bias is the comparison between shark attacks and falling coconuts.

Sharks dominate public perception due to media coverage, films, and cultural storytelling. However, they cause only around 10 deaths per year globally.

Falling coconuts, by contrast, are estimated to cause approximately 150 deaths annually.

Despite this, most people intuitively perceive sharks as the greater threat because dramatic, emotionally charged events are more easily recalled.

This illustrates a core principle of availability bias:

what is easiest to remember is often mistaken for what is most likely.

Countering availability bias in decision-making

Reducing the impact of availability bias in business decision-making requires deliberately changing how information is collected, interpreted, and weighted.

Look beyond recent data

Avoid relying only on recent events when making decisions.

Instead, actively incorporate:

• 5–10 year historical trends
• long-term performance cycles
• multiple economic or market conditions

This helps counter recency-driven distortions created by availability bias.

Broaden information input

One of the strongest ways to reduce availability bias is to expand the diversity of inputs.

This includes:

• cross-functional perspectives
• regional or market differences
• external stakeholders or advisors

A broader information base reduces overreliance on whatever is most mentally accessible.

Question the emotional weight of information

Before reacting to any high-impact or dramatic event, pause and ask:

Is this truly representative, or simply more memorable?

This simple question helps separate emotional salience from statistical significance — a core challenge in managing availability bias.

Replace intuition with structured thinking

Structured decision-making frameworks reduce the influence of cognitive bias in business decision-making, including availability bias.

Examples include:

• structured risk assessments
• multi-source validation
• decisions evaluated across multiple time horizons
• predefined decision criteria

This ensures that isolated, vivid events do not disproportionately influence outcomes.

Slow down decision-making

Availability bias is driven by fast, intuitive thinking (System 1).

Slowing down decision-making activates more analytical reasoning (System 2), allowing leaders to evaluate evidence rather than react to memory strength.

Even small pauses can significantly reduce bias-driven errors.

In essence: why availability bias matters

Availability bias is not just a psychological concept — it is a structural influence on how organisations prioritise, allocate resources, and assess risk.

It shapes:

• what leaders notice
• what feels urgent
• what gets funded
• what gets ignored

By actively counteracting availability bias through broader input, structured thinking, and slower decision-making, organisations move toward bias-aware leadership.

This leads to decisions grounded in evidence rather than visibility — and ultimately, more resilient long-term strategy,

The post Availability Bias in Business: Why Urgency Is Often an Illusion appeared first on Pontis Technology.

Over the years, working on various web applications, I’ve run into a recurring problem: routing solutions that are either too opinionated for small projects or too bare-bones to handle dynamic URLs properly. So I built a minimal PHP router class that hits the middle ground. Clean URLs, HTTP method handling, dynamic parameters, controller dispatch, all in a single self-contained file.

This article walks through how it works, step by step.

The complete class is designed to be copied directly into any PHP project. No external dependencies, no configuration required.

The problem with traditional PHP URLs

The traditional PHP approach to request handling relies on individual files per endpoint. A client calls something like:

http://www.my-simple-api-service.com/get-product-data.php?id=57

As the number of parameters grows, this becomes unmanageable – very quickly:

http://www.my-simple-api-service.com/get-product-data.php?id=57&number_of_items=100&startpage=5&start_timestamp=123456...

This puts a burden on both sides of the request. The API consumer has to construct long, fragile URLs. The backend has to parse a growing list of query parameters and build increasingly complex logic around them.

Modern frameworks solve this with URL rewriting and routing. The same request becomes:

http://www.my-simple-api-service.com/products/57/100/123456

The URL is cleaner, the parameters are positional, and a routing layer maps the request to the right controller method automatically.

The mechanism behind this is URL rewriting: instead of loading a specific .php file for every request, the server redirects everything to a single entry point (typically index.php), and the router takes it from there.

You don’t always need Laravel. This guide walks through building a minimal PHP router class from scratch. One you can drop into any project with no configuration and no external dependencies.

Building the router class

Here’s how the class is structured, section by section.

1. Defining valid HTTP methods

The first thing the router needs to know is which HTTP methods it supports. I kept it to the four most common ones:

const VALID_METHODS = ['GET', 'POST', 'PUT', 'DELETE'];

This constant is used later to validate incoming route definitions and reject anything unsupported early, rather than letting an invalid method cause a silent failure downstream.

2. Storing routes

Routes are held in a static array on the class. Each entry stores the route string, HTTP method, controller name, action name, and the compiled regex pattern:

private static array $routes = [];

Using a static array keeps the class self-contained and avoids any dependency on a database or external state.

3. Adding routes

The addRoute() method is the core of route registration. It validates the HTTP method, checks that the controller action is in the expected Controller@action format, and stores the compiled route:

public static function addRoute(string $routeString, string $httpMethod, string $controllerAction): void

{

    if (!in_array($httpMethod, static::VALID_METHODS)) {

        throw new \InvalidArgumentException("Invalid HTTP method: $httpMethod");

    }

    if (!str_contains($controllerAction, '@')) {

        throw new \InvalidArgumentException("Invalid route action format. Expected 'Controller@method'.");

    }

    [$controller, $action] = explode('@', $controllerAction, 2);

    static::$routes[] = [

        "routeString"    => $routeString,

        "httpMethod"     => $httpMethod,

        "controllerName" => $controller,

        "actionName"     => $action,

        "regex"          => static::compileRouteRegex($routeString),

    ];

}

Throwing exceptions on invalid input means misconfigurations surface immediately during development rather than producing unexpected behaviour in production.

4. Helper methods for common HTTP methods

To keep route definitions readable, the class exposes convenience methods for each HTTP verb. Instead of calling addRoute() directly, you can use:

public static function get(string $routeString, string $controllerAction)

{

    static::addRoute($routeString, 'GET', $controllerAction);

}

public static function post(string $routeString, string $controllerAction)

{

    static::addRoute($routeString, 'POST', $controllerAction);

}

The same pattern applies to put() and delete(). These are thin wrappers, but they make route definitions in index.php much easier to read.

5. Handling incoming requests

This is where the routing actually happens. The handleRequest() method normalises the incoming URI, loops through stored routes, matches against the compiled regex, and dispatches to the correct controller action:

public static function handleRequest(string $requestUri, string $requestHttpMethod): mixed

{

    $normalizedUri = trim($requestUri, '/');

    $normalizedUri = strtok($normalizedUri, '?') ?: '';

    foreach (self::$routes as $route) {

        if ($route['httpMethod'] !== $requestHttpMethod) continue;

        $params = static::matches($route['regex'], $normalizedUri);

        if ($params !== false) {

            foreach ($params as &$param) {

                if (is_numeric($param)) $param = (int) $param;

            }

            if (!class_exists($route['controllerName'])) {

                throw new \Exception('Controller not found: ' . $route['controllerName']);

            }

            if (!method_exists($route['controllerName'], $route['actionName'])) {

                throw new \Exception("Method '{$route['actionName']}' not found in controller " . $route['controllerName']);

            }

            $controller = new($route['controllerName']);

            return $controller->{$route['actionName']}(...$params);

        }

    }

    return null; // No matching route — handle 404 externally

}

A few things worth noting here. The URI is stripped of leading/trailing slashes and query strings before matching, so the regex patterns stay simple. Numeric parameters are cast to integers automatically. If the controller class or method doesn’t exist, an exception is thrown rather than failing silently.

6. Compiling route patterns to regex

Dynamic route parameters like {id} need to be converted into named regex capture groups. The compileRouteRegex() method handles this:

private static function compileRouteRegex(string $routePattern): string

{

    $routePattern = trim($routePattern, '/');

    $parts = explode('/', $routePattern);

    $patternParts = array_map(function ($part) {

        if (preg_match('/^\{(.+?)(?::(.+?))?\}$/', $part, $matches)) {

            $paramName    = $matches[1];

            $paramPattern = $matches[2] ?? '[a-zA-Z0-9\-\_]+';

            return "(?P<$paramName>$paramPattern)";

        }

        return preg_quote($part, '/');

    }, $parts);

    return '^' . implode('/', $patternParts) . '$';

}

For example, the route /product/{id} compiles to the regex ^product/(?P<id>[a-zA-Z0-9\-\_]+)$. The named capture group makes it straightforward to extract the id value from the URI and pass it directly to the controller method.

7. Matching the request URI

The actual regex matching is handled by a separate private method that keeps handleRequest() clean:

private static function matches(string $routeRegex, string $requestUri): array|bool

{

    return (preg_match("~{$routeRegex}~", $requestUri, $matches))

        ? array_filter($matches, fn($key) => !is_int($key), ARRAY_FILTER_USE_KEY)

        : false;

}

If the match succeeds, only the named captures (the actual parameter values) are returned and the numeric keys from preg_match are filtered out. If there’s no match, the method returns false.

8. Missing routes

When no route matches, handleRequest() returns null. This keeps the router itself simple and leaves 404 handling to the application layer. For a web application that means a custom 404 page; for an API it means returning the correct HTTP response code.

Server configuration: the .htaccess file

The router only works if all requests are directed to index.php first. On Apache, that means a .htaccess file in the project root with URL rewriting rules:

RewriteEngine On

# Send all requests to index.php (skip real files and directories)

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.*)$ index.php [QSA,L]

What each rule does:

• RewriteEngine On  enables Apache’s mod_rewrite module
• RewriteCond %{REQUEST_FILENAME} !-f skips rewriting if the request points to a real file (images, CSS, JS). These are served directly
• RewriteCond %{REQUEST_FILENAME} !-d skips rewriting if the request points to a real directory
• RewriteRule ^(.*)$ index.php [QSA,L]  rewrites everything else to index.php. The [QSA] flag preserves any query parameters; [L] marks this as the final rule

This is the same rewriting pattern used by Laravel, WordPress and most other PHP frameworks. If you’ve deployed any of them on Apache, this will be familiar.

Using the router

1. Define your routes

In your index.php or a dedicated routes file:

require_once 'Router.php';

Router::get('/product/{id}',  'ProductController@show');

Router::post('/product',       'ProductController@create');

Router::put('/product/{id}',  'ProductController@update');

Router::delete('/product/{id}', 'ProductController@delete');

2. Create a controller

class ProductController

{

    public function show($id)

    {

        echo 'Displaying product with ID: ' . $id;

    }

    public function create()

    {

        echo 'Creating a new product.';

    }

    public function update($id)

    {

        echo 'Updating product with ID: ' . $id;

    }

    public function delete($id)

    {

        echo 'Deleting product with ID: ' . $id;

    }

}

3. Handle the incoming request

In index.php:

require_once 'Router.php';

require_once 'ProductController.php';

$requestUri    = $_SERVER['REQUEST_URI'];

$requestMethod = $_SERVER['REQUEST_METHOD'];

$response = Router::handleRequest($requestUri, $requestMethod);

if ($response === null) {

    // For web: render a 404 page

    // For API: http_response_code(404); echo json_encode(['error' => 'Not found']);

    echo '404 Not Found';

}

A GET request to /product/57 will match the first route, instantiate ProductController, call show(57), and return the result.

Strengths and limitations

What this PHP router class does well

• No dependencies. Copy the file into any project and it works. No Composer, no configuration, no setup
• Clean dynamic routing. Named capture groups in the regex make parameter extraction readable and reliable
• Explicit validation. Invalid HTTP methods and malformed controller actions fail loudly at route registration time, not at request time
• Easy to extend. Adding middleware support, route groups or additional HTTP methods (e.g. PATCH) requires minimal changes to the existing structure

Current limitations of the PHP router class

• Integer parameters only. The automatic type casting currently handles numeric strings as integers. String parameters are passed through as-is
• Linear route matching. All routes are iterated on every request. For applications with a large number of routes, grouping routes by HTTP method (separate arrays per method) would reduce the lookup cost
• No built-in 404 handling. Returning null keeps the class flexible, but it means the application layer needs to handle missing routes explicitly. This is a deliberate trade-off, not an oversight
• Apache-specific rewriting. The provided configuration assumes Apache with mod_rewrite. Nginx requires a different approach, a location block with try_files instead of .htaccess.

Conclusion

This PHP router class will not replace a full framework. It is not designed to. What it does is give you a clean, readable routing layer for projects where a framework would be excessive, like a small internal API, a lightweight microservice or a quick prototype.

The complete class is around 80 lines. It handles dynamic routes, validates input, dispatches to controllers and stays entirely self-contained. For the right project, that’s exactly what you need.

If you extend it with middleware support, route grouping or Nginx configuration, I’d be glad to hear how you approached it.

Now that you’re up to speed with PHP router class, maybe you’re interested in this:

The post How to Build a Minimal PHP Router Class from Scratch  appeared first on Pontis Technology.

Every business decision starts somewhere. A number on a slide, an example that comes to mind, or a success story circulating at the last industry event. These starting points feel incidental, but they are rarely neutral.

Two cognitive biases, anchoring and survivorship bias, make this problem particularly costly in business environments. Anchoring bias locks teams onto the first figure they encounter, shaping every estimate, negotiation and forecast that follows.

Survivorship bias distorts strategy by drawing lessons only from visible successes, while the far larger body of failures disappears from the data entirely.

This article explains how each works, where they show up most often in business and project settings, and what leaders can do to reduce their grip.

Anchoring bias: When the first number wins

Anchoring bias occurs when people rely too heavily on the first piece of information they encounter when making a decision.¹ That initial figure, estimate or idea becomes a reference point that pulls all subsequent judgments toward it, even when better data arrives later.

The adjustment people make away from the anchor is almost always insufficient. The result is that the final decision ends up closer to that original number than the evidence actually warrants.

Negotiations and pricing

A used-car dealer opens with an intentionally high asking price. The eventual discount feels like a win, even when the final figure is still inflated. The same psychology surfaces in hiring: the first salary figure on the table quietly defines the range of the entire negotiation, regardless of whether it has any real grounding in the role or market.

Budgeting and planning

When a project’s first estimate lands at, say, €500,000, it becomes surprisingly difficult for teams to accept that the real scope may require twice that amount. The early number functions as a mental benchmark that quietly resists revision, even as new information comes in. In agile environments, if one developer casually estimates eight weeks, the group tends to gravitate toward that figure rather than forming independent assessments, often resulting in collective underestimation of actual effort.

Strategy and ideation

In brainstorming sessions, the first idea put on the table casts a long shadow. Teams tend to evaluate subsequent proposals relative to it, giving the opening idea disproportionate weight. Over time, the discussion narrows around that early suggestion, and potentially stronger options never receive a fair hearing.²

Anchoring is particularly stubborn because it doesn’t spare experienced people. Studies show that real-estate agents’ property valuations are pulled toward the listed asking price even when they believe their judgment is fully independent.² Once an anchor is in place, people also tend to seek out information that confirms it, tightening the bias’s grip on the final decision.

How to counter anchoring bias

The most effective approach is to slow down before the first number takes hold. A few practices worth building into decision-making processes:

• Gather independent references before opening a discussion. Look at multiple benchmarks, cost comparisons or past project data before any internal figure is floated. This reduces the gap between the anchor and reality.
• Challenge the number explicitly. Ask: if this figure were twice as high, or half as low, would we make the same decision? Forcing the question surfaces how much hidden work the anchor is doing.
• Collect estimates anonymously. When teams share numbers before group discussion, early guesses can’t quietly shape everyone else’s thinking. Anonymous polling or written estimates before a meeting significantly reduces anchoring effects.
• Treat the first number as a rough draft. Leaders set the tone here. When they frame early estimates as a starting point rather than a target, teams feel permission to keep questioning, adjusting and revising as new data arrives.

From the first cost estimate that becomes a silent benchmark to the success stories that hide a far larger number of failures, anchoring and survivorship bias are two of the most expensive distortions in business decision-making.

Survivorship Bias: What the Data Isn’t Showing You

Survivorship bias happens when we focus only on the visible successes and draw conclusions from them, while overlooking the much larger group of attempts that failed and disappeared from view. The result is a distorted picture of what works, what’s realistic and what the actual odds are.

In business, failure rarely makes it into the case study. Successful companies get interviews, conference keynotes and articles. Companies that followed the same strategy and failed quietly disappear. Over time, this creates the illusion that success is more predictable and more common than it truly is.

Strategy and best practices

Leaders study Apple, Google or the latest unicorn and try to extract transferable lessons. But the thousands of companies that attempted similar strategies and fell short are absent from that analysis. As Farnam Street researchers³ note, companies that fail early are ignored while rare successes are celebrated for years, creating a distorted sense of which approaches reliably work. The winning company’s path appears to be a formula, when in reality, many others followed the same formula and failed.

Product development

A software team that analyses only its active, paying users is studying the survivors. Customers who churned, leads who never converted and features that never gained traction are missing from that dataset. The team ends up investing in what current users love while missing the insights hidden in the products, features and customer relationships that didn’t make it. Without a clear-eyed look at failure, it’s easy to build confidently in the wrong direction.

A famous illustration

During World War II, Allied engineers studied the bullet holes on bombers that returned from missions and proposed reinforcing the areas that had sustained the most damage. The logic seemed sound, until statistician Abraham Wald pointed out the flaw: they were only looking at the planes that made it back. The aircraft shot down in truly critical areas never returned to be counted. The right response was to reinforce the areas with no visible damage, because those were the spots where a hit meant the plane didn’t survive. The most important data was the data that was missing entirely.

How to counter survivorship bias

The core habit is straightforward: flip the question. For every success you’re analysing, actively seek out the equivalent failures.

• Study failures as rigorously as successes. Post-mortems shouldn’t be reserved for projects that shipped. Failed initiatives, churned customers and abandoned ideas are often richer sources of learning than polished success stories.
• Seek out the voices that usually go unheard. Interview customers who didn’t convert. Talk to employees who resigned. Review projects that were quietly shelved. These perspectives reveal blind spots that success stories never surface.
• Put the real base rates on the table. Before committing to a bold strategy, look at the historical success rate of similar attempts in your industry. If one in ten comparable initiatives typically succeeds, that context belongs in the decision. It doesn’t kill ambition, it grounds it.
• Assign someone to ask the uncomfortable question. When a success story is being used as evidence that something works, someone in the room should always ask: what about the ones that didn’t? A formal “critical challenger” role ensures failure data doesn’t get quietly bypassed.

Survivorship bias is, at its core, a blind spot in how we construct reality. When leaders give failure the same analytical weight as success, decisions become grounded in evidence rather than in polished winner stories.

Up next: Part 3 covers availability bias and the framing effect, two forces that show how a single vivid event can quietly redirect strategy, and how the same restructuring plan can appear as a win or a loss depending solely on how it is presented.

Frequently Asked Questions

Now that you’re up to speed with part 2, perhaps you would like to remind yourself of part 1

Sources

¹ J. Perfetti, “The Bias Trap,” Duke Corporate Education, 2025. Available: https://www.dukece.com/insights/the-bias-trap/

² “Mental Model: Anchoring,” Farnam Street Blog, 2008. Available: https://fs.blog/mental-model-anchoring/

³ “Survivorship Bias: The Tale of Forgotten Failures,” Farnam Street Blog, 2019. Available: https://fs.blog/survivorship-bias/

Atlassian, “5 Cognitive Bias Examples and How to Avoid Them in Decision-Making,” Atlassian Blog, 2019. Available: https://www.atlassian.com/blog/productivity/cognitive-bias-examples

F. Gottlob, “How to Avoid Survivorship Bias in Product Management,” Medium, 2025. Available: https://medium.com/@falkgottlob/how-to-avoid-survivorship-bias-in-product-management-lessons-from-the-british-bomber-study-25edb8ab4ab7

The post The First Number in the Room: How Anchoring and Survivorship Bias Distort Business Decisions appeared first on Pontis Technology.

In this post we will be discussing the differences in Node.js vs Next.js. Which stack is better for what.

Everyone building a modern web application eventually faces the same question: which stack to choose.

In the world of web development, the JavaScript ecosystem offers a dizzying array of choices. Two of the most popular approaches for building modern web applications are using Node.js with React.js or leveraging the all-in-one power of Next.js.

At our company, we’ve had the opportunity to build real-world projects with both stacks.

In this post, we’ll explain what these approaches are, who they are best suited for, when each makes sense, where they differ in practice, why those differences matter, and how to choose between them. So, basically, Node.js vs Next.js.

We’ll share what we’ve learned, highlight the strengths and weaknesses of each approach, and offer practical guidance for teams facing the same decision.

The Problem: Choosing the Right Stack for Your Web App

Choosing the right stack is rarely just a technical decision. It affects development speed, scalability, team structure and long-term maintenance. If you’re a developer, tech lead, or product manager, you’ve probably asked yourself:

“Should we build our next app with Node.js and React, or just use Next.js?”

The answer isn’t always obvious.

Each approach has its own trade-offs in terms of flexibility, performance, scalability and developer experience.

Making the right choice can save your team time, reduce technical debt, and help you deliver a better product.

Background: What Are Node.js, React.js, and Next.js?  

Before comparing approaches, it helps to clearly define what each technology does and how they fit together.

• Node.js is a JavaScript runtime that lets you run JavaScript on the server. It’s commonly used to build APIs, handle backend logic, and serve data to frontend applications.
• React.js is a frontend library for building user interfaces. It’s component-based, fast, and has a huge ecosystem.
• Next.js is a React framework that adds server-side rendering (SSR), static site generation (SSG), API routes, and more. It aims to simplify the process of building production-ready React apps.

Node.js vs Next.js explained through real project experience. Understand the trade-offs in architecture, SEO, scalability, and development speed.

Our Experience: Projects with Node.js + React.js

The Node.js + React.js approach represents a more traditional separation between frontend and backend systems. We’ve built several projects using the classic combination of Node.js for the backend and React.js for the frontend.

Typically, this means two separate codebases: one for the API (Node.js with Express) and one for the client (React).

What we liked

There are clear advantages to this architecture, especially when flexibility and separation are important.

• Separation of concerns: The backend and frontend are clearly separated, making it easier to scale teams and services independently.
• Backend flexibility: We could use any Node.js libraries, set up custom authentication, and design our API exactly as needed.
• Frontend freedom: The React app could be deployed anywhere (S3, Vercel, Netlify), and we had full control over the build process.

Challenges we faced

At the same time, this separation introduces additional complexity.

• Setup complexity: Managing two codebases means more boilerplate, more deployment steps, and more room for configuration errors (CORS, environment variables, etc.).
• SEO limitations: Out-of-the-box, React apps are client-side rendered, which isn’t ideal for SEO or initial load performance.
• Data fetching: We had to manually handle data fetching, loading states, and error handling between the client and server.

Example

A concrete example helps illustrate when this approach works well.

We developed a custom application for one of our clients using the Node.js + React.js stack.

The backend, built with Node.js, managed complex data processing and handled secure authentication, while the React frontend delivered a highly interactive and responsive user experience.

This clear separation between backend and frontend allowed us to tailor each part of the system to the client’s specific needs.

Since the app was designed for authenticated users rather than public access, SEO was not a primary concern, making this architecture an ideal fit for the project.

Our Experience: Projects with Next.js

Next.js takes a different approach by combining frontend and backend capabilities into a single framework. We’ve also delivered projects using Next.js as the main framework.

Next.js combines the frontend and backend into a single codebase, offering features like SSR, SSG, and API routes out of the box.

What we liked

This approach simplifies many common development tasks.

• Built-in SSR and SSG: Pages can be rendered on the server or statically generated, which is great for SEO and performance.
• Unified codebase: Having both frontend and backend logic in one place made development and deployment simpler.
• File-based routing: Creating new pages is as easy as adding a file to the pages directory – no need to configure React Router.
• API routes: For simple backend needs (like form submissions or authentication), we could use Next.js API routes without spinning up a separate server.
• Server Components (Next.js 14+): The introduction of Server Components allows us to render parts of the UI on the server by default, reducing client-side JavaScript and improving performance. This feature makes it easier to fetch data securely and efficiently, and helps keep the client bundle smaller.

Challenges we faced       

However, the unified approach also introduces trade-offs.

• Backend limitations: For complex backend logic or heavy data processing, Next.js API routes can feel limiting. In those cases, we still needed a separate Node.js service.
• Learning curve: Developers used to traditional React apps had to adjust to Next.js conventions.
• Tighter coupling: The frontend and backend are more tightly integrated, which can be a downside for very large teams or projects with strict separation requirements.

Example

Another example shows where this approach performs well. We also built a CRM application for a client using Next.js.

In this case, our main reason for choosing Next.js wasn’t server-side rendering, but rather the speed and efficiency it offered during development.

The framework’s file-based routing, built-in API routes, and unified codebase allowed our team to move quickly and maintain a clean, organized project structure.

This approach helped us deliver a robust solution on a tight timeline, while still benefiting from Next.js features like easy component sharing and streamlined deployment.

Key Differences and When to Use Each

To make the comparison more practical, it helps to look at how these approaches differ across specific areas.

SEO

When it comes to SEO, Node.js + React.js requires extra setup for server-side rendering (SSR), while Next.js offers built-in SSR and static site generation (SSG), making it much easier to achieve great SEO right out of the box.

Routing

For routing, Node.js + React.js involves manual setup using React Router or similar libraries. In contrast, Next.js provides file-based, automatic routing – creating a new page is as simple as adding a file to the pages directory.

APIs

Regarding APIs, Node.js + React.js requires a separate server, such as Express, to handle backend or API logic. Next.js, on the other hand, includes built-in API routes that are perfect for simple backend needs.

Flexibility

In terms of flexibility, Node.js + React.js gives you maximum freedom to customize everything as you like. Next.js introduces some constraints due to its conventions, but this also means it’s much simpler and faster to get started.

Setup

The setup process with Node.js + React.js typically involves more boilerplate and configuration. With Next.js, you can get up and running quickly with less configuration and setup required.

Scaling

Finally, scaling is another area where the two approaches differ. Node.js + React.js makes it easy to scale the frontend and backend separately, which is useful for larger or more complex systems. Next.js is best suited for unified projects where the frontend and backend are closely integrated.

Tips and Advice

Once the differences are clear, the choice becomes easier depending on project needs.

Choose Node.js + React.js if:

• You need a clear separation between frontend and backend.
• Your backend is complex or needs to scale independently.
• You want maximum flexibility in your architecture.

Choose Next.js if:

• SEO and performance are priorities.
• You want to move fast with less boilerplate.
• Your backend needs are simple, or you’re building a content-driven site or portal.

Hybrid approach

In some cases, combining both approaches can be useful. For some projects, we’ve used Next.js for the frontend and a separate Node.js API for heavy backend logic.

This gives you the best of both worlds, though it adds some complexity.

Conclusion

Choosing between Node.js vs Next.js is less about which one is better, and more about which one fits your context. Both Node.js + React.js and Next.js are excellent choices, but they shine in different scenarios.

Our experience building real projects with both stacks has shown that the right choice depends on your project’s requirements, your team’s expertise, and your long-term goals.

If you value flexibility and have complex backend needs, the classic Node.js + React.js split is hard to beat.

If you want speed, simplicity, and great SEO out of the box, Next.js is a fantastic option.

Now that you’re up to speed with Node.js vs Next.js, how about learning a bit more about wordpress and payload cms?

The post Node.js + React.js vs Next.js: Lessons from Real Projects appeared first on Pontis Technology.

Quietly, almost invisibly, biases slip into boardrooms, hiring panels and crisis meetings, steering decisions in ways no one notices until the damage is done. Research from McKinsey¹ shows that major decisions made with robust debate and active bias awareness are 2.3 times more likely to succeed. That’s not a marginal edge – that’s a structural advantage.

So, what are we actually dealing with?

The Four Biases Shaping Business Decisions Right Now

There are dozens of documented cognitive biases, but four show up consistently in business and project environments, often with the highest cost ²:

Anchoring bias causes teams to over-rely on the first number or idea they encounter. That initial figure becomes the invisible benchmark, and every subsequent judgment quietly orbits around it, even when better data arrives later.

Survivorship bias distorts strategy by drawing lessons only from visible successes. When failure quietly disappears from the data, leaders are left optimizing for a reality that doesn’t fully exist.

Availability bias makes whatever is most recent or emotionally vivid feel most important. A single headline, a competitor’s crisis or a memorable anecdote can quietly redirect millions in budget not because the data supports it, but because it’s top of mind.

The framing effect shows that the same information can trigger completely different decisions depending on how it’s presented. “200 jobs saved” and “400 jobs lost” describe the same restructuring plan, but they rarely produce the same response in the room.

Where This Series Comes From

This three-part series grew out of an interactive internal workshop at Pontis Technology, led by Benjamin Kardum (Senior Project Manager) and Ana Schauperl (People and Culture Specialist). The workshop brought together cross-functional teams to explore how cognitive biases influence real-world decision-making in business and project environments not first in theory, but in the kind of situations most leaders face every week.

The goal was straightforward: make the invisible visible. Because bias doesn’t announce itself. It works through the path of least resistance. Through the first number on a slide, the loudest voice in the room, the success story that gets cited most often.

Cognitive biases in business decision-making slip into boardrooms, hiring panels and crisis meetings every day. This guide introduces the four most costly biases in business decision-making and what leaders can do to counter them.

What Bias-Aware Leadership Actually Looks Like

Bias-aware leadership isn’t about eliminating intuition or slowing every decision to a crawl. It’s about building the habits and structures that catch distortion before it hardens into a costly misjudgement.

That means encouraging independent estimates before group discussion, reviewing failures with the same rigour applied to successes, questioning what data is missing, not just what’s on the table, and deliberately reframing decisions to test whether the conclusion changes with the wording.

None of this is complicated. But it does require intention. And in organisations where speed is rewarded and confident decisions are celebrated, slowing down to ask, “what are we not seeing?” takes real leadership.

Follow our blog on cognitive biases in business decision-making to read the full series

Part 2 will cover anchoring bias and survivorship bias. Two of the most common and most expensive distortions in business decision-making, with practical techniques for recognizing and countering their influence.

Part 3 will turn to availability bias and the framing effect, showing how a single vivid event can quietly redirect strategy, and how the same restructuring plan can appear as a win or a loss depending solely on how it is presented.

Frequently Asked Questions

Now that you’ve read this, maybe you would like to know why US companies are outsourcing their software & AI projects

Sources

¹ “Biases in decision-making: A guide for CFOs,” McKinsey & Company, Mar. 20, 2025. Available: https://www.mckinsey.com/capabilities/strategy-and-corporate-finance/our-insights/biases-in-decision-making-a-guide-for-cfos

² Atlassian, “5 Cognitive Bias Examples and How to Avoid Them in Decision-Making,” Atlassian Blog, 2019. Available: https://www.atlassian.com/blog/productivity/cognitive-bias-examples

The post Why Smart Leaders Still Make Bad Decisions (And What’s Really Behind It) appeared first on Pontis Technology.

To be able to use pointers in C#, we need to introduce the unsafe keyword and understand how unsafe contexts work. This article explains what unsafe code is, how pointers can be used in C#, and when using unsafe code might make sense.

TL;DR

Unsafe code lets us use pointers and pointer operations inside C# code. We can only use pointers inside an unsafe code block. Classes, structs and functions can be declared as unsafe, letting us write unsafe code within them.

Fixed arrays can only be declared inside unsafe structs, not classes. The keyword fixed pins a variable address on the heap and doesn’t let the garbage collector move it. To iterate through an array, we need to use the fixed keyword.

For 99% of situations, you won’t need to use the unsafe feature, but it can come in handy if your situation is in the other 1%.

What Is Unsafe Context in C#?

To be able to use and compile code that uses the unsafe keyword, we have to enable the AllowUnsafeBlocks compiler option.

We can enable it by editing the .csproj file and adding the following:

After enabling it, we can start messing around with pointers.

What are Pointers in C#?

What are pointers? Pointers are special variables that store the memory address of another variable. We can obtain the value of a memory location by dereferencing the pointer (we won’t be going in-depth into pointers, memory and such in this post).

So, how do we use pointers in C#? Well, we can only use pointers and pointer operations inside an unsafe block.

Example: Declaring and Using a Pointer

Pointers allow direct memory access, but they must always be used carefully to avoid unintended behavior.

Unsafe Functions

We can also declare unsafe functions, which marks all the code inside the function as unsafe, and lets us write unsafe code inside the function.

Example: Unsafe Function

To use this function, we have to declare a block of code as unsafe. Like in the example bellow:

Using Unsafe With Structs and Classes

Structs and classes can also be marked as unsafe. One key difference is that in an unsafe struct, we can declare a fixed array inside a struct, while we cannot do that inside an unsafe class.

Unsafe Structs and Fixed Arrays

Unsafe Classes

Declaring fixed arrays inside unsafe classes is not allowed and will result in a compilation error.

Marking a class as unsafe (just as with marking a function as unsafe) lets us write unsafe code inside the class without using the unsafe keyword.

The fixed Keyword Explained

You might have noticed the fixed keyword and asked yourselves what it means, well the keyword “fixed” prevents the variable from moving by pinning it on the heap.

This keyword is primarily used with:

• Array elements
• Strings (since strings can be treated as character arrays)

What causes the variable to move? The garbage collector can move the variable to another address. Since the address of a fixed variable cannot be changed, we can be pretty sure that our pointer points to the correct memory address and to the correct value located at that address.

The next example demonstrates changing a character in a string by using the unsafe context in C#.

The above code gives the following output:

Benchmark: Comparing Performance

And last, but certainly not least, here is a benchmark that shows the difference in speed and memory efficiency of changing a letter in a string. There are 4 methods used in this benchmark:

• .Substrings
• StringBuilder
• Spans
• Pointers (unsafe)

The string used for this benchmark is the following

string word = “This benchmark should show a difference in speed and memory allocation.”;

In this string, we are changing the full stop at the end of the string into an exclamation mark.  

Let’s take a look at the benchmark results.

We can see that using pointers to change a letter in a string is a lot faster and no memory is allocated. Why is that? All these methods, except the unsafe method (which uses pointers), create a copy of the string we want to change and that new string holds our change. This means that, effectively we have two different strings, one without the change and one with the change.

The method that uses the pointer, on the other hand, accesses the memory location of the string, finds the position of the character that needs to be changed, and changes it. This does not allocate any memory since we are not creating a new instance of a string, but just changing a character at a specific memory location.

To show this, we can check for reference equality

The result of this code is as follows:

Should You Use Unsafe Code?

Probably not. If you are writing performance critical code, then you might consider using unsafe code (or you could also consider using a lower level programming language like C).

 But, beware that if you are not comfortable with what you are doing, you might cause more issues, even having the code run slower than just not using unsafe code.

Conclusion

While using unsafe code in C# might give you some performance benefits, it doesn’t mean that you should use unsafe code. In 99% of situations, you won’t need to use unsafe code, but for the 1% of situations, it is good to know that unsafe code exists and that it could help you.

If you decide that your situation is in those 1%, then be careful with using this feature as it might cause more issues if you are not comfortable with pointers and lower level code.

Additional Resources

For more information about unsafe context in C#, see the official documentation:
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/unsafe

The post Unsafe Context in C#: Working With Pointers appeared first on Pontis Technology.

WordPress helps you move fast with a familiar ecosystem. Payload CMS gives you more control with a modern, code-first approach.

This comparison is based on real project work, plus what I keep hearing from other developers. The goal is simple: help you pick what fits your next build.

A personal view based on real project work and what others say

When I compare WordPress and Payload, I think about three things:

1. How building feels
2. How comfortable maintenance is after launch
3. What happens if I need to extend or migrate things

For a typical site with a blog, resources such as PDFs or downloads, and maybe an events list, both WordPress and Payload can do the job. The key difference is whether I want to move fast with familiar tools or build something more flexible and custom from the ground up.

WordPress: what works well and what I’ve learned

WordPress has been my go-to for most of my web projects. With WordPress I often start a project by installing it on hosting, as many hosts provide a one-click install. Logging into the dashboard shows the basic structure immediately. Posts, media library, pages everything is already there:

• Posts
• Pages
• Media library
• Users

For a blog or resource site, this means I can jump into content quickly.

A practical WordPress and Payload CMS comparison based on real project work, including how each platform handles speed, flexibility, migrations and long-term maintenance.

Resources and events in WordPress

Building the resources section inside WordPress feels natural. I define custom fields manually or use simple custom code if needed. Events, if needed, often come via a plugin that handles calendars or listings. Most common needs get covered fast:

• Blog
• Pages
• Resource library

• Simple event listings

When plugins do not fully fit

When the available plugins do not have what’s needed, I often use Code snippets, a plugin that allows injecting custom PHP or JavaScript code directly into WordPress. With that, I can create:

• Custom widgets
• Shortcodes
• Small features that unblock the project

This flexibility has saved me many times when a plugin did not fully meet the requirement or extra content was stuck behind a paywall.

Why migrations matter

In real projects, clients change hosting, staging environments, or rebuild infrastructure. Migrating a site becomes part of maintenance. I have moved WordPress sites many times from staging to production or between hosts, mainly in two ways

Option 1: Manual migration

This is the full-control route:

• Download files
• Export the database
• Upload to the new server
• Import the database

This is common when using cPanel or Plesk.

Option 2: Migration tools

Migration plugins or managed hosting tools can package and move the site automatically. For standard sites that mostly use core features, a handful of plugins and simple custom code, this has worked reliably for me.

What I always check after migration

After a migration, I test the site carefully:

• Permalinks
• Media paths
• Plugin behavior
• Pages
• Posts

Sometimes permalinks just need a refresh. Sometimes a plugin behaves differently on a new host. Testing makes the difference between a smooth migration and a frustrating one.

What WordPress handles well

WordPress is ideal when I need a working site fast. It is familiar, handles most standard website needs out of the box, and when prebuilt solutions do not cut it I can code custom behaviour. It works especially well for sites with a blog, resources, a few pages, and maybe events. My migration experience adds confidence because I know the common pitfalls and how to fix them reliably.

Where WordPress begins to struggle

When the project becomes complex or requires unusual data structures, WordPress can feel heavy.

• Too many plugins can create conflicts and maintenance overhead
• Performance tuning often becomes a separate task
• The admin can feel cluttered as custom code and plugins stack up

For security, scalability, and tight data control, WordPress can manage, but it usually requires careful plugin selection, constant updates, and hosting optimisation.

Using Payload CMS

Payload starts differently. Instead of a ready-to-go CMS with themes and plugins, it gives a clean backend. I define content models such as blog posts, resources, and events directly in code. Payload builds the admin panel automatically based on the code.

This means I start by defining the data schema, not by picking themes or browsing plugin directories. The backend remains clean, typed, structured, and clear.

Since Payload is headless, I also build the frontend. This is usually linked to a modern frontend stack such as React or Next.js. I control layout, logic, styling, and routing entirely myself.

What developers like about Payload

Payload scores highly for flexibility, developer friendliness, and speed of development. Developers like that Payload can handle simple blogs as well as complex applications. Its API-first approach makes it useful for projects where content needs to appear in multiple places.

Payload’s admin panel is clean and minimal, without the clutter of plugin-heavy systems.

Some drawbacks are the smaller community and fewer prebuilt features. Compared to WordPress, developers need to build more themselves.

Where Payload is ideal

Payload works best when you need:

• Custom content models that will evolve
• A modern frontend stack
• Content reused across multiple products or platforms
• Tight control over structure, performance and security

Where Payload demands more effort

The initial build takes longer. Everything must be defined in code, both backend and frontend. Small teams or non-technical users may find this more challenging than using WordPress. The smaller ecosystem also means some features available as WordPress plugins must be built manually or sourced from packages.

WordPress and Payload analogy

WordPress is like a prebuilt house. The house is already built and you just need to decorate and buy furniture. You can move in quickly and start living, but you are limited by the existing walls and spaces. You cannot easily change the structure.

Payload is like a blueprint for a house. You need to build most of it yourself, from the frame to the rooms. This takes more effort and time, but you have freedom to create the spaces exactly as you want. You decide where walls go, how rooms are shaped, and how everything connects. This gives more options and flexibility, but you have to do the work to get there.

Choosing between them

I usually decide like this:

Choose WordPress if you need:

• Fast delivery

• A familiar admin experience for clients

• An ecosystem that covers most standard needs

• A site that is mostly content, with limited custom logic

Choose Payload CMS if you need:

• Custom content models

• A modern frontend like Next.js

• Content reused across multiple frontends

• Long-term flexibility and cleaner architecture

Final word

WordPress has been reliable for years. I know how to build, migrate, and extend it. It works well for small to medium sites and when speed and client familiarity are priorities.

Payload offers clean architecture, modern admin interface, and flexibility. It is ideal for complex, multi-platform, or long-term projects. It takes more effort but delivers control and scalability.

The choice depends on project needs, timelines, and how much control is required.

FAQ

Now that you’ve read this, how about some more knowledge on C#

The post WordPress and Payload CMS: Which One Fits Your Next Project? appeared first on Pontis Technology.

That is where a Technical Writer makes all the difference. By treating documentation as part of the development process and not an afterthought, Technical Writers ensure that every release is supported by clear guidance. They help teams move faster by reducing rework, keep developers and business aligned through consistent communication and build trust with users who depend on clarity in a high-stakes industry.

What Is Docs-as-Code?

Docs-as-Code is a modern way of creating documentation using the same tools and workflows developers use for software. Instead of Word files or wikis, documentation lives in the codebase. Writers draft in Markdown, store content in Git and publish it through CI/CD pipelines with tools like Docusaurus, open-source framework that lets teams publish documentation.

• Git makes it easy to manage versions of documentation, track changes and work on branches for new features before merging them into the main set.
• Docusaurus then takes those Markdown files and builds a structured site with navigation, search and theming, so content is both easy to maintain behind the scenes and easy to use for readers.

The result is documentation that evolves alongside the product. Every feature, update or bug fix includes corresponding documentation changes. When the code ships, the Docs are ready too.

For example, a Fintech team struggled to keep documentation aligned with frequent API updates, which caused onboarding delays and support issues. After moving to a Docs-as-Code approach, documentation became part of every release cycle, reducing errors and improving developer adoption.

Collaboration Across Teams

Technical Writers do not work in isolation. They collaborate with developers to track new features and update documentation through pull requests in Git, ensuring that content is reviewed alongside code before it is merged. They partner with SMEs (Subject-Matter Experts) and compliance teams to translate complex rules into clear guides and procedures that meet regulatory standards. They work with QA and Support teams to turn tricky scenarios and recurring questions into troubleshooting content that saves time for both users and staff. They also align with DevOps to maintain pipelines that automatically build and publish documentation sites, with drafts often tested in pre-release environments so accuracy can be confirmed before going live.

By embedding themselves in every stage of the process, Technical Writers make documentation a shared responsibility, with Engineers contributing directly and Writers refining content for clarity and consistency until it is ready for release.

In fintech, clarity is part of the product. This post explains how Technical Writers use Docs-as-Code to keep API documentation, compliance content and releases aligned so teams ship faster with fewer mistakes.

Tools of the Trade

Modern Technical Writers rely on the same toolkit as developers, which allows them to stay aligned with the software development process and contribute directly within the same workflows:

• Markdown provides a lightweight, readable format for writing. It is simple to learn, easy to edit in any text editor and ideal for storing in version control
• Git brings full version control to documentation. Every edit is tracked, branches can be created for new features and content is only merged after review, ensuring accuracy and accountability.
• Docusaurus turns Markdown into professional documentation websites. These tools generate clean navigation, built-in search and consistent design, so users get a polished experience without Writers needing to code front-end layouts.
• OpenAPI uses YAML to define APIs in a structured way, describing endpoints, parameters and responses. From these files, teams generate interactive Docs that stay aligned with the code. Technical Writers add examples and explanations, so the specs become clear, accurate and easy for developers to use in Fintech integrations.
• CI/CD pipelines automate the heavy lifting of publishing. Once a change is merged, pipelines run quality checks for broken links or formatting errors, build the static site and deploy it automatically.

With this toolkit, Fintech teams can deliver documentation as reliably as they deliver software, making sure that users always have access to information that is current, consistent and trustworthy.

From Chaos to Clarity: Why It Matters in Fintech

Fintech moves fast. While working as part of a major global bank’s payment solutions team, I experienced first-hand how difficult it can be to keep documentation aligned with frequent API releases across multiple regions.

Each new update introduced small but critical changes, and integration partners often relied on outdated specifications, causing delays and repetitive testing issues. By adopting a Docs-as-Code workflow, we made documentation part of the same CI/CD process as the product itself.

Every code deployment included reviewed and updated content, which dramatically reduced integration errors, improved onboarding speed and increased overall trust in the platform. Writers and developers collaborate in Git and every merge automatically updates the Docs site.

The result is a single source of truth, trusted by the entire organization. Support questions drop, onboarding accelerates and users feel confident using the product.

Docs-as-Code keeps everything aligned:

• Faster onboarding: New hires and partners get up to speed quickly with accurate, accessible guides.
• Reduced support load: Users can self-serve answers, cutting down on repetitive tickets.
• Better compliance: Version control provides an audit trail, ensuring every change is documented.
• Smoother releases: Documentation ships with the product, eliminating last-minute scrambles.

The Strategic Value of Fintech Technical Writers

For fintech technical writers, the job is not “making docs nicer”, it is protecting speed, clarity and auditability at the same time. They manage knowledge by turning scattered information into a structured and reliable source of truth. They align processes by creating standards and templates that keep teams consistent across projects. They advocate for users by asking the questions end users would ask and ensuring products are explained in a way that builds confidence. They also scale documentation by designing workflows that keep content accurate and manageable as products grow.

In Fintech, where trust and clarity are essential, this role is strategic. A Technical Writer makes sure every release is understood, every audit is covered and every customer has the information they need to succeed.

Conclusion

Great Fintech products aren’t defined by code alone. They succeed when people understand how to use them. Technical Writers, equipped with Docs-as-Code workflows, make that possible. By embedding documentation in the development pipeline, they turn it into a living asset that grows with the product.

For Fintech teams, this means faster releases, stronger compliance, happier customers and less internal friction. In a competitive market, clear documentation isn’t just support material, it’s part of the product itself. And behind every great product experience, there’s a Technical Writer making it clear.

FAQ

Now that you’ve read this, maybe you’re interested in learning about business analyst documentation and why it matters.

The post Clear Docs, Clear Profits: Why Fintech Needs Technical Writers appeared first on Pontis Technology.