DEV Community: Amara Wallis

Microservices vs. Monolithic Architecture: What Should Your Full-Stack Development Partner Build?

Amara Wallis — Fri, 19 Jun 2026 08:37:03 +0000

A founder asked me last year to review the architecture his agency had pitched. Eleven services. A message queue. A service mesh. The product was a booking tool with a calendar and a checkout screen, and it had no users yet.

That's the trap in one screenshot. The architecture question shows up early, it sounds like an engineering footnote, and it quietly sets your hosting bill, your shipping speed, your hiring plan, and how much sleep you'll trade for 2am pages. Monolith or microservices is not a small decision. So before you hand a full-stack development company a budget and a buzzword, it pays to know what each one really costs you.

Just build the monolith (most of the time)

One codebase. One thing to deploy. One database. It's boring, and boring is underrated.

This isn't me being a Luddite. Martin Fowler made the "MonolithFirst" case back in 2015, and it has aged well: on day one you don't know your own domain boundaries well enough to split them in the right spots. Cut too early and you cut wrong, then you're paying to move walls that should never have gone up. DHH, who wrote Rails, has a name for the opposite instinct. He calls it the Majestic Monolith, and Basecamp still runs on one.

In practice, a monolith is just easier to live with while the team is small. You call a function instead of standing up an API. One test suite. One deploy. And when something tips over at 2am, the stack trace points at the bug, not at a flaky network hop between two services that may not even be involved.

Where microservices earn their keep

They're not a fad. They fix a real and fairly narrow problem, and it's an org problem more often than a tech one. Several teams, each owning a service, each shipping on its own clock, nobody blocking anybody. One endpoint that has to scale hard without dragging the rest of the app with it. Netflix is the story everyone cites. A bad database failure took their monolith down in 2008, and they spent years afterward splitting into hundreds of services so one fault couldn't sink the ship.

You pay for it every single day, though. Calls that were free in memory now cross the network, so latency, retries, and half-completed requests become yours to handle. Data spreads across services, and keeping it consistent turns into its own roadmap. You need tracing, centralized logs, and an on-call crew that can follow one request as it ricochets through five or six systems at 3am.

Here's the bit people gloss over. Take on all that machinery without the tooling and the headcount to run it, and you don't get microservices. You get a distributed monolith: every cost of the network, none of the independence. That's the one outcome worth dreading.

The Amazon story everyone misquotes

You've probably seen this one passed around with a smug "microservices are dead" caption slapped on it. The real version is more interesting, and a lot more specific.

In 2023, the team running Prime Video's audio and video quality monitoring wrote up how they rebuilt it. They'd gone serverless, on AWS Step Functions and Lambda, with video frames handed between steps through S3. At their scale, the orchestration overhead and those storage round-trips piled up fast. So they folded the whole thing back into a single process inside one container. Infrastructure cost fell by more than 90%, and it scaled better on top of that.

Read the small print, though. This was one internal tool, not the entire Prime Video platform, and Amazon didn't disown microservices. The real takeaway is quieter and more honest: for that particular job, the fashionable choice was simply the wrong one.

The middle ground nobody sells you

There's a third option that almost never lands in a proposal, mostly because it's hard to make sound impressive: the modular monolith. Still one app. Still one deploy. But you put firm walls between domains inside the codebase. Billing can't reach into the guts of orders. Each module has a front door and keeps everything else private.

Shopify is the obvious example. Their core is a Rails monolith running into the millions of lines, sliced into dozens of components, with an in-house tool called Packwerk that fails the build the second one module reaches into another's internals. GitHub's still a monolith. So is Gusto. All of them well beyond the size where people assume you have no choice but to break apart.

It's a good trade. You get the clean boundaries and the team sanity, and you dodge the network tax completely. And when a domain really does outgrow the monolith, carving out a module that already has firm edges is a weekend of work, not a quarter. You earn the right to split by drawing the line in code first and seeing whether it holds.

How to make the call

Skip the theory and sit with a few uncomfortable questions.

Team size first. If three people are going to own all of it, you don't have the bodies to run separate services plus the on-call rotation they drag along. Boundaries next: if the product is still shifting week to week, any line you draw now will be in the wrong place by next month, so leave it soft. Then operations, the unglamorous part. Tracing, log aggregation, automated rollbacks, a working rotation. Missing those? Microservices will bite. And scale, last. Not "we might blow up" scale, which is a daydream, but a concrete path you can point at that has to grow on its own.

If most of your answers are "not yet," there's your answer. Build the monolith, keep it modular, and look again in a year with traffic data instead of vibes.

So what do you tell the agency?

When you sit down with a full-stack development company, don't ask for "microservices" because the word feels future-proof. Tell them what the product does, who's going to maintain it, and how fast it's likely to change. Let the shape of the system fall out of those three answers.
A partner worth keeping will push back if you ask for ten services to ship a v1. That pushback is a green flag, not a difficult vendor. Ask how they'd stop a monolith from rotting into spaghetti, how they'd handle background jobs and the schema, and what specific signal would make them pull a service out later. A full-stack development company that can only sell you the buzzword, and can't walk you through the trade-offs in plain language, has told you something useful without meaning to.

The short version

Almost nothing dies because it picked the wrong deploy topology. Products die because they never shipped. Microservices are a way to scale an organization, and the day you have that problem for real, go for it. Until then? A clean monolith with solid interior walls is the cheapest, fastest thing you can put in front of real users. Build that one. Then let the traffic tell you what, if anything, is worth breaking off.

Accessibility-First Web Development: A Practical Framework

Amara Wallis — Tue, 16 Jun 2026 12:38:19 +0000

Here's a question most businesses never think to ask when they're building a website: can everyone actually use this?

Not just the people on a fast laptop with perfect vision and a reliable internet connection. Everyone. The person navigating your site with a screen reader because they're visually impaired. The user who can't use a mouse and relies entirely on a keyboard. The individual with a cognitive disability who needs clear, consistent layouts to make sense of what they're looking at.

If your website doesn't work for these people, it doesn't work full stop. And yet, accessibility is almost always the last thing discussed in a web development project, usually buried somewhere at the bottom of a checklist, treated as a nice-to-have instead of a requirement.

That needs to change. Not because of legal compliance (though that's a real consideration too), but because accessibility-first web development simply produces better websites. Faster load times, cleaner code, better SEO, higher user retention accessible design delivers all of that. The framework isn't complicated. It just requires thinking about it from the start instead of trying to bolt it on at the end.

This is that framework.

What Accessibility-First Web Development Actually Means

Accessibility-first is a mindset, not a checklist. It means building with the full range of human experience in mind from day one not auditing for compliance after the site is already live.

It's Not the Same as Compliance

WCAG (Web Content Accessibility Guidelines) is the global standard for web accessibility. Most businesses know it exists. Very few understand what it actually requires or that meeting WCAG 2.1 AA standards isn't a ceiling, it's a floor.

Compliance means you passed the audit. Accessibility-first means you thought about disabled users during architecture decisions, during design reviews, during content writing, and during QA. Compliance is a document. Accessibility-first is a process.

The gap between the two matters because an audit-passing website can still be genuinely terrible to use if you have a disability. Screen reader compatibility on paper doesn't mean the experience of navigating your site with a screen reader is actually usable. Accessibility-first development closes that gap.

Who It's Actually For

Here's a number that surprises most people: roughly 1 in 4 adults in the US lives with some form of disability. Globally, that figure touches over a billion people. But accessibility-first design doesn't only serve people with permanent disabilities.

Consider situational limitations someone using a phone in bright sunlight who can't see the screen clearly, a person with a broken wrist who can't use a mouse, a new parent holding a baby with one hand. Accessible design serves all of them. When you build for the edges, the center gets better by default. That's the business case, and it's a strong one.

The Practical Framework: How to Build Accessibility-First

This is where most guides go vague. They tell you accessibility matters and then hand you a list of WCAG criteria with no sense of what to actually do or in what order. Here's a real, sequenced approach.

Start With Semantic HTML: Before Anything Else

Everything in accessibility-first development starts with the structure of your HTML. Semantic HTML using the right elements for the right purposes is the foundation that everything else depends on.

A element tells a screen reader it's a button. A styled to look like a button tells a screen reader nothing. A landmark helps keyboard users jump to navigation. An unlabeled is invisible to assistive technology. The fix isn't complicated it just has to happen at the code level, which means your website development company needs to treat semantic markup as a non-negotiable standard, not an optional refinement.

This is the kind of decision that's almost free to get right from the start and extremely expensive to fix after a site is built. A full semantic HTML audit on a large existing site can take weeks. Building with it correctly from day one takes minutes per component.

Build Keyboard Navigation Into Every Interaction

A significant portion of users navigate entirely without a mouse. This includes people using screen readers, people with motor impairments, and power users who simply prefer keyboard shortcuts. Every interactive element on your website every link, form field, dropdown, modal, and button needs to be reachable and operable with a keyboard alone.

In practice, this means managing focus states carefully. When a user opens a modal with a keyboard, focus should move into the modal. When they close it, focus should return to where it was. Tab order should follow the visual layout of the page. Focus indicators the visible outline that shows which element is selected should never be removed via CSS just because a designer finds them visually inconvenient.

Testing this is straightforward. Open your site. Put the mouse aside. Try to complete a real task using only the Tab, Enter, and arrow keys. If you get stuck, something is broken.

Design Color and Contrast to Work for Everyone

Color contrast failures are the single most common accessibility violation found in web audits. WCAG requires a contrast ratio of at least 4.5:1 for normal text against its background. Most designers know this. Many still ship designs that don't meet it because the visual check on a high-quality monitor looked fine.

The problem is that screens vary wildly brightness, calibration, ambient lighting. What looks perfectly readable on a designer's display can become invisible on a standard office monitor in a bright room. Tools like the WebAIM Contrast Checker make this easy to verify. Running contrast checks during the design phase, not after development, saves everyone time.

Color should also never be the only way information is communicated. An error message that shows only in red, with no icon or text label, is invisible to a colorblind user. This is a common pattern in form validation, and it's an easy one to fix just add a supporting indicator that doesn't rely on color alone.

Write Alt Text That Actually Describes the Image

Alt text is possibly the most misunderstood accessibility feature in web development. Most developers know to add it. Most add it badly.

Alt text that says "image" or repeats the file name ("banner-hero-final-v3.jpg") provides zero value to a screen reader user. Alt text that describes what's actually in the image and why it's there makes visual content accessible. A product photo should describe the product. An infographic should summarize what it communicates. A decorative image that adds no information should have an empty alt attribute (alt="") so screen readers skip it entirely.

This is a content responsibility as much as a development one. Whoever writes and uploads content to a website needs to understand how alt text works and why it matters. Building accessibility into your content process not just your code is what separates accessibility-first thinking from a one-time technical fix.

Test With Real Assistive Technology

You cannot fully evaluate the accessibility of a website using only automated tools. Tools like Axe or Lighthouse catch roughly 30-40% of accessibility issues. The rest only surface when you actually use a screen reader, a keyboard, or voice navigation software to interact with the site.

NVDA and JAWS are the most widely used screen readers on Windows. VoiceOver is built into macOS and iOS. Testing with at least one of these should be a standard part of every QA cycle, not a one-off audit. If your development team doesn't currently include this in their process, it's worth raising with whoever manages your project.

The goal isn't to simulate disability it's to catch the real gaps that automated checks miss before a disabled user encounters them.

Why Accessibility-First Wins Beyond Compliance

Accessibility-first development isn't a sacrifice. It consistently produces outcomes that benefit every user, not just those with disabilities.

SEO and Accessibility Are Closer Than You Think

Search engines and screen readers have more in common than most people realize. Both rely on semantic structure to understand what a page is about. Both benefit from descriptive alt text, proper heading hierarchy, and meaningful link labels. Both struggle with content that's buried in non-semantic markup or dependent on visual context to make sense.

Building accessible means building in a way that search engines can properly index and rank. The same practices that make a site navigable with a screen reader make it more readable to a crawler. A proper frontend development company treats SEO and accessibility as parallel tracks because in practice, they almost always are.

Final Words

Accessibility-first web development isn't a niche concern for large enterprises with legal teams. It's a practical standard that any team building for real users should be operating to.

The framework is simpler than it sounds: start with semantic HTML, build for keyboard navigation, check your contrast ratios, write meaningful alt text, and test with real assistive technology. Do these things from the beginning of a project instead of the end, and the cost is minimal. Retrofit them onto an existing site, and you're looking at a significant investment of time and money.

More than that, accessibility-first development forces clarity. Clean structure. Logical flow. Content that communicates clearly without depending on visual tricks. Those are qualities that make websites better for everyone not just the users who need them most.

The best time to build accessibility was day one. The next best time is now.

Technical requirements for a website to be 'AI-crawlable' and 'LLM-ready' in 2026

Amara Wallis — Tue, 09 Jun 2026 10:21:16 +0000

The search behaviour of people has changed more in the last two years than it did in the previous decade.

You must have noticed that when you search for something on Google, instead of a list of links, you get a written answer at the top. That answer even cites two or three top-performing websites. And you must have analyzed everyone below those gets ignored.

In the earlier days of 2026, this was happening in roughly one out of every four Google searches, and in fields like B2B tech and healthcare, it’s even closer to 80% of searches.

The websites getting cited under the AI overview sections aren’t just the one with the best content. They are the ones built in a way that AI systems can actually read. There are various technical requirements of the AI system, and this blog covers all of these requirements.

How AI Reads Your Website (It's Not Like Google)

Most people believe in the harsh myth that AI tools work exactly like Google crawls the web, stores everything, rank it later. But in reality, it doesn’t work this way.

Google’s crawlers visit your pages, save the content, and build an index. However, AI crawlers like ClaudeBot (Anthropic) or GPTBot (OpenAI) are more selective. They only come to your site if they need something specific, pull the most useful text from your content, and use it to build a complete answer. Consider it less like indexing and more like skimming a document to answer a question.

This creates a very practical problem. If an AI bot can't access your site or can't read your content clearly, it will skip you regardless of how well your site ranks on Google. The two systems are related, but they're not the same.

1. Are You Actually Letting AI Bots In?

This is one of the primary issues that most website owners are not even aware of—whether it is happening at all, especially when it comes to website development services.

AI crawlers have their personal bots, like GPTBot, which is for OpenAI, and ClaudeBot, which is for Anthropic. And Google uses Google-Extended for its AI products. Perplexity uses PerplexityBot. So, check today if your website’s robots.txt file has a rule that automatically blocks unknown bots; all these get turned away at the door.

You do not have to make a severe change to enable all the known bots; all you have to do is simply add these lines to your robots.txt file.

`User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: PerplexityBot
Allow: /`

If you want to block your sensitive areas, like the admin panel or checkout pages, you can still do that. You just have to make sure that AI bots can reach your public content.

One more thing that you should definitely know: Google has confirmed that blocking Google-Extended has zero effect on your regular search rankings. This step only stops your content from feeding into Gemini and other Google AI products. There is no reason to block it unless you specifically don't want your content used for AI training.

2. Can Your Content Actually Be Read?

Here's a problem that catches a lot of modern websites off guard.

Many websites today are built with frameworks like React or Vue. These apps load a nearly empty HTML page first, then JavaScript fills in all the actual content. For a human visitor using a browser, this is invisible everything appears instantly. For an AI crawler that doesn't run JavaScript, the page looks empty.

There's an easy way to check. Open any important page on your site and press Ctrl+U (or right-click and select "View Page Source"). Look at the raw code. Can you see your headline, your paragraphs, your main content? If all you see is a shell with a bunch of script tags and no actual text, AI bots see the same blank page.

The solution is to make sure your content is built into the HTML before it reaches the visitor this is called Server-Side Rendering (SSR). If you're using Next.js, Nuxt, or SvelteKit, this is built in. If you're on an older setup, tools like Prerender.io can handle it.

The content that specifically needs to be visible in the raw HTML: your headings, your opening paragraphs, any statistics or data points, FAQ sections, and comparison tables.

3. Help AI Understand What Your Page Is About

Writing tells AI what you're saying. Schema markup tells AI what your page actually is.

Schema is a bit of behind-the-scenes code (usually added as a JSON-LD block) that labels your content for machines. It answers questions like: Is this a blog post or a product page? Who wrote it? When was it published? What company is behind this website?

Without schema, AI systems have to guess these things from context. With schema, there's no guessing. Pages with proper schema markup get cited up to three times more often in AI answers than comparable pages without it (AirOps, 2026).
The types that matter most right now:

Organization: your business name, website, logo, and contact info
Article or BlogPosting: for every blog post you publish
FAQPage: for any Q&A sections on your pages
HowTo: for step-by-step guides

One small thing that makes a bigger difference than most people expect: keep your brand name, author names, and service names worded the exact same way on every single page. AI models use these consistent labels to recognize and trust who you are. If your company is called "Acme Solutions" on one page and "Acme Solutions Ltd." on another, that creates confusion at the machine level.

4. A New File Called llms.txt

This one is brand new most websites still haven't heard of it.

In 2025, a standard emerged called llms.txt. It's a simple plain-text file you place at the root of your website (so it lives at yourdomain.com/llms.txt). Inside, you list your most important pages with short descriptions of what each one covers, written in basic Markdown.

The idea behind it is practical. AI agents doing live lookups don't crawl your entire site. They look for easy entry points clean, readable files that tell them what's worth reading. The llms.txt file is that entry point. It's like handing an AI a curated table of contents for your site instead of making it figure things out on its own.

Keep it short and honest. Only list pages that are publicly accessible. Popular SEO tools like Yoast have already adopted the file and is gaining traction fast.

5. Write Your Content So It Can Be Pulled Out Cleanly

Even if every technical requirement above is met, how you write your content still decides whether it gets cited.

Here's one data point that should change how you structure every article. Research from Growth Memo (2026) found that nearly 44% of all AI citations come from the first 30% of a page meaning the intro. If your main point is buried in paragraph seven, AI systems may never pull it.

A few practical things to change:

Start each section by directly answering the question in the heading. Don't warm up for three sentences first just answer it. Use comparison tables instead of writing comparisons in paragraph form. Tables are much easier for AI to extract cleanly. Keep your key facts dates, statistics, prices as actual text on the page, not inside images or loaded in through JavaScript.

Short sentences in the parts you want cited also help. Not everywhere, just in the sections where you're making a direct claim. In AI development and content, pages with shorter sentence lengths in those sections earn measurably more AI citations, according to AirOps research from 2026.

Final Words

The honest answer is that visitors who find you through an AI citation convert at 4.4 times the rate of visitors from regular organic search. They arrive having already been pointed to you by something they trust. That's a very different kind of traffic.

None of what's listed here requires rebuilding your website. The robots.txt change takes five minutes. The llms.txt file takes twenty. Schema and rendering fixes take longer but are well within reach of any developer.

The websites showing up in AI answers right now aren't necessarily the biggest or the most well-known. A lot of them are just the ones that made themselves easy to read. That's a gap that's still very much closeable.

Building Flutter Desktop Apps: A Practical Tutorial

Amara Wallis — Thu, 07 May 2026 07:09:08 +0000

In the initial stage, Flutter started it's journey as a mobile framework but now it has grown into something more powerful and bigger. Now, Flutter can be seamlessly used to build fully native desktop apps for Windows, macOS, and Linux from a single codebase system using Dart programming language.

Whether you are working as a sole developer developing a productivity tool or working with any Flutter app development company delivering cross-platform software to clients, Flutter desktop gives you the same hot reload speed, the same widget system, and the same rendering engine you already know from mobile, just in a resizable native window that users can run on their computers.

This tutorial walks you through everything from scratch. You will learn how to set up your environment, create your first desktop app, understand the folder structure, build a real working project with code examples, handle desktop-specific UI patterns, and package your app for release. Move forward to learn each and everything.

What Is Flutter Desktop and Why Should You Care?

Flutter desktop no longer remains as an experimental side feature. It has now reached a stage for stable status for Windows in February 2022, followed by macOS and Linux, and in 2026 it has become completely production-ready target that thousands of developers use to ship real software.

Flutter Desktop vs. Electron: What's the Difference?

Electron bundles a full Chromium browser inside your app to render the UI, which is why Electron apps are often large and slow to launch. Flutter desktop compiles your Dart code directly to native machine code no browser, no JavaScript runtime, no extra overhead attached.

Flutter Draws Its Own UI: It Doesn't Use Native Widgets

Unlike React Native or other frameworks that map components to native OS controls, Flutter renders every pixel itself using the Impeller graphics engine. This means your app looks exactly the same on Windows, macOS, and Linux no platform-specific styling bugs to hunt down.

A Single Codebase for Three Operating Systems

You write your app once in Dart. Flutter builds it as a .exe for Windows, a .app for macOS, and an ELF binary for Linux. The same lib/ folder, the same widgets, the same business logic just different build targets.

Desktop Is Stable and Actively Maintained

Flutter desktop is not a beta feature. As of Flutter 3.19 (released in 2024), all three desktop platforms are fully supported with regular performance improvements, bug fixes, and growing package ecosystem support from the community.

Setting Up Your Flutter Desktop Environment

Before you write a single line of code, your environment needs to be ready. Here's exactly what to install on each platform no guesswork.

Install the Flutter SDK (Version 3.19 or Later)

Download the Flutter SDK from flutter.dev and extract it to a path without spaces or special characters. Add flutter/bin to your system's PATH variable so the flutter command works in any terminal. On Windows, do this through System Properties → Environment Variables → Path.

Run flutter doctor to Check Everything

After installation, open a terminal and run:

flutter doctor

This command checks for missing tools, misconfigured SDKs, and platform-specific requirements. Fix every issue it reports before moving forward; ignoring warnings here causes build failures later.

Windows: Install Visual Studio With C++ Workload

Flutter desktop on Windows needs Visual Studio 2022 (not VS Code) with the Desktop development with C++ workload installed. This provides the MSVC compiler Flutter uses to build Windows binaries. Without it, flutter run -d windows will fail immediately.

macOS: Install Xcode and CocoaPods

Install Xcode from the Mac App Store, then run this in your terminal:

sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
sudo gem install cocoapods

CocoaPods is required because Flutter's macOS plugin system uses it for dependency management. Skip it and plugin builds will break.

Linux: Install GTK Development Libraries

On Ubuntu or any Debian-based Linux, run:

sudo apt-get install clang cmake ninja-build pkg-config libgtk-3-dev

Flutter uses GTK3 as the windowing backend on Linux. These packages give Flutter the low-level libraries it needs to create and manage native windows on your desktop.

Enable Your Desktop Target

Run the appropriate command for your platform:

flutter config --enable-windows-desktop
flutter config --enable-macos-desktop
flutter config --enable-linux-desktop

Without this step, your platform won't appear as a device option when you run flutter devices. This is the most commonly skipped step that confuses beginners.

Creating Your First Flutter Desktop App

With the environment ready, let's create a real project and see it run in a native desktop window.

Create the Project

flutter create my_desktop_app
cd my_desktop_app

This scaffolds a complete Flutter project with platform-specific folders alongside your lib/ directory. You'll see windows/, macos/, and linux/ folders each containing native build configuration files Flutter uses to compile for that OS.

Run It on Your Desktop

flutter run -d windows   # or -d macos / -d linux

A native window opens with the default Flutter counter app. It's resizable, it has a title bar, and it responds to your OS's window controls minimize, maximize, close just like any real desktop application.

Hot Reload Works Here Too

While the app is running, press r in the terminal to trigger hot reload. Changes to your Dart code in lib/ reflect instantly in the window. This is the same hot reload experience from mobile development it works identically on desktop and saves enormous amounts of time during UI iteration.

The Folder Structure You Need to Understand

Your lib/main.dart is where your Dart code lives. The windows/, macos/, and linux/ folders contain the native project files a Visual Studio solution for Windows, an Xcode workspace for macOS, and CMake files for Linux. You rarely need to touch these manually, but knowing they exist helps when platform-specific build errors appear.

Building a Real App: A Simple Note-Taking Tool

Rather than just explaining the counter app, let's build something you'd actually use a note-taking app where you can type notes and save them to a file. This covers real desktop patterns: multi-line text input, file system access, and a clean layout.

The Complete main.dart

Replace the contents of lib/main.dart with this:

import 'dart:io';
import 'package:flutter/material.dart';
import 'package:path_provider/path_provider.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'NoteDesk',
      debugShowCheckedModeBanner: false,
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.indigo),
        useMaterial3: true,
      ),
      home: const NoteScreen(),
    );
  }
}

class NoteScreen extends StatefulWidget {
  const NoteScreen({super.key});

  @override
  State<NoteScreen> createState() => _NoteScreenState();
}

class _NoteScreenState extends State<NoteScreen> {
  final TextEditingController _controller = TextEditingController();
  String _status = 'Start typing your note...';

  Future<void> _saveNote() async {
    final directory = await getApplicationDocumentsDirectory();
    final file = File('${directory.path}/my_note.txt');
    await file.writeAsString(_controller.text);
    setState(() {
      _status = 'Note saved to ${file.path}';
    });
  }

  Future<void> _loadNote() async {
    final directory = await getApplicationDocumentsDirectory();
    final file = File('${directory.path}/my_note.txt');
    if (await file.exists()) {
      final content = await file.readAsString();
      setState(() {
        _controller.text = content;
        _status = 'Note loaded successfully';
      });
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('NoteDesk'),
        backgroundColor: Colors.indigo,
        foregroundColor: Colors.white,
        actions: [
          IconButton(
            icon: const Icon(Icons.folder_open),
            tooltip: 'Load Note',
            onPressed: _loadNote,
          ),
          IconButton(
            icon: const Icon(Icons.save),
            tooltip: 'Save Note',
            onPressed: _saveNote,
          ),
        ],
      ),
      body: Padding(
        padding: const EdgeInsets.all(16.0),
        child: Column(
          children: [
            Expanded(
              child: TextField(
                controller: _controller,
                maxLines: null,
                expands: true,
                keyboardType: TextInputType.multiline,
                style: const TextStyle(fontSize: 16),
                decoration: const InputDecoration(
                  hintText: 'Write your note here...',
                  border: OutlineInputBorder(),
                ),
              ),
            ),
            const SizedBox(height: 12),
            Text(
              _status,
              style: const TextStyle(color: Colors.grey, fontSize: 13),
            ),
          ],
        ),
      ),
    );
  }
}

Add the path_provider Package

Open pubspec.yaml and add this under dependencies:

dependencies:

flutter:
    sdk: flutter
  path_provider: ^2.1.2

Then run:

flutter pub get

The path_provider package gives you access to the user's Documents folder on all three desktop platforms Windows, macOS, and Linux with a single API call. No platform-specific code needed.

What This Code Does

The _saveNote() function gets the app's documents directory using getApplicationDocumentsDirectory(), then writes the text from the TextField into a .txt file using Dart's built-in File class. The _loadNote() function reads that same file back and fills the text field. Both functions update a status message at the bottom so the user always knows what just happened.

Run It and Test

flutter run -d windows

Type something in the text field, click the save icon, and check your Documents folder the file is there. Click the load icon to pull it back. This is full file system access in a Flutter desktop app, working out of the box.

Desktop-Specific UI Patterns You Need to Know

Mobile UI doesn't automatically feel right on desktop. There are patterns desktop users expect that you need to add intentionally.

Setting Window Title and Minimum Size

Add the window_manager package to pubspec.yaml:

window_manager: ^0.3.8

Then update your main() function:

import 'package:window_manager/window_manager.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await windowManager.ensureInitialized();

  WindowOptions windowOptions = const WindowOptions(
    size: Size(900, 600),
    minimumSize: Size(600, 400),
    title: 'NoteDesk',
    center: true,
  );

  await windowManager.waitUntilReadyToShow(windowOptions, () async {
    await windowManager.show();
    await windowManager.focus();
  });

  runApp(const MyApp());
}

This sets the window to 900×600 pixels on launch, prevents the user from resizing below 600×400 (which would break your layout), centers it on screen, and sets the title bar text. These are basic details every desktop app should handle and most Flutter tutorials skip them entirely.

Adding Keyboard Shortcuts

Desktop users rely on keyboard shortcuts. Add Ctrl+S to save the note by wrapping your widget tree:

@override
Widget build(BuildContext context) {
  return Shortcuts(
    shortcuts: {
      LogicalKeySet(LogicalKeyboardKey.control, LogicalKeyboardKey.keyS):
          const SaveIntent(),
    },
    child: Actions(
      actions: {
        SaveIntent: CallbackAction<SaveIntent>(
          onInvoke: (intent) => _saveNote(),
        ),
      },
      child: Focus(
        autofocus: true,
        child: Scaffold(
          // ... your existing scaffold
        ),
      ),
    ),
  );
}

class SaveIntent extends Intent {
  const SaveIntent();
}

This maps Ctrl+S directly to the _saveNote() function. On macOS, use LogicalKeyboardKey.meta instead of LogicalKeyboardKey.control for the Command key. Keyboard shortcuts like this make your app feel native users reach for them instinctively on desktop.

Cursor Changes on Hover

Wrap any clickable element with MouseRegion to show the correct cursor:

MouseRegion(
  cursor: SystemMouseCursors.click,
  child: GestureDetector(
    onTap: _saveNote,
    child: const Text('Save'),
  ),
)

This is a small thing that makes a noticeable difference. When users hover over a button and the cursor doesn't change to a pointer, the app feels unfinished. On mobile this doesn't matter on desktop it absolutely does.

Packaging and Distributing Your Flutter Desktop App

Building locally is one thing. Getting your app onto other people's computers requires proper packaging for each platform.

Build a Release Binary for Windows

flutter build windows --release

The output lives in build/windows/x64/runner/Release/. This folder contains your .exe file and several required .dll files. You must distribute the entire folder the .exe alone won't run on another machine without its DLL dependencies sitting next to it.

Create a Windows Installer With the msix Package

Add msix to your dev dependencies:

dev_dependencies:
  msix: ^3.16.7

Add this block to your pubspec.yaml:

msix_config:
  display_name: NoteDesk
  publisher_display_name: Your Name
  identity_name: com.yourname.notedesk
  msix_version: 1.0.0.0
  logo_path: assets/icon.png

Then run,

flutter pub run msix:create

This generates a .msix installer file that users can double-click to install your app cleanly on Windows 10 and 11. It handles file associations, start menu entries, and uninstallation automatically.

Build for macOS

flutter build macos --release

The .app bundle is in build/macos/Build/Products/Release/. For distributing outside the Mac App Store, you need to codesign with an Apple Developer certificate and run Apple's notarization process. Unsigned apps trigger Gatekeeper warnings users see a scary "this app can't be opened" message, which kills adoption fast.

Build for Linux and Create an AppImage

flutter build linux --release

The output is in build/linux/x64/release/bundle/. Package it as an AppImage using appimagetool so it runs on any Linux distribution without requiring installation. AppImages are self-contained and portable they're the most practical Linux distribution format for Flutter desktop apps.

Common Mistakes to Avoid

Every developer runs into these when building their first Flutter desktop app. Knowing them in advance saves you hours of debugging.

Using Packages Without Checking Desktop Support

Not every pub.dev package works on desktop. Always check the platform support badges on the package page before adding it to your project. Packages that use Android or iOS platform channels will throw MissingPluginException at runtime on desktop and that error won't appear until you actually run the relevant code path.

Forgetting to Handle the Window Close Event

If your app has unsaved data, intercept the close event before the window disappears. Use windowManager.setPreventClose(true) and implement the WindowListener interface to show a confirmation dialog. Without this, users lose their work silently which is unacceptable in a desktop app.

Hard-Coding Mobile-Scale Touch Targets

Buttons designed for 48dp mobile touch targets feel oversized on desktop where users have a mouse cursor that's pixel-precise. Scale down your padding and interactive element sizes for desktop layouts. Users notice when everything feels puffed up and designed for thumbs instead of a pointer.

Ignoring Window Size and State Persistence

Desktop users expect apps to remember their window size and position between sessions. Save the window dimensions on close and restore them on launch using window_manager. An app that always opens at the same fixed size in the center of the screen feels rigid and unpolished compared to every other app on the desktop.

Final Words

Flutter desktop has genuinely arrived. The tooling is solid, the performance is native, and the developer experience is exactly what you'd expect from a Flutter app development company shipping production software. You get hot reload, a massive widget library, full file system access, and a single codebase that targets Windows, macOS, and Linux without compromise.

The note-taking app in this tutorial is simple by design but the patterns it demonstrates scale directly to complex real-world software. File I/O, keyboard shortcuts, window management, and proper packaging all follow the same principles whether you're building a text editor or a full enterprise desktop tool.

Start with something small, get it running on your machine, then build from there. Flutter desktop rewards developers who take it seriously and the bar for standing out is still low enough that a well-built app gets noticed.

Why We Switched from WordPress to Headless CMS + Next.js

Amara Wallis — Thu, 30 Apr 2026 17:11:46 +0000

Let me just start with the reality that we didn’t want to leave WordPress like every other startup. We have been running our site on WordPress for the last 6 years now. We have a clearly defined plugin setup; it has boring deployments, but it is good, and it worked perfectly until we required scalability.

The loopholes in WordPress didn’t show up all at once; it was something like a slow drip. It came with a security patch that broke a plugin, a Lighthouse score that wouldn't budge no matter what we tried. A staging sync that wiped three weeks of content edits on a Friday afternoon. Each problem had a fix. But after six years, the fixes had fixes, and the whole thing felt less like a website and more like a Jenga tower we were scared to touch.

We ship web products for a living. A slow, fragile site doesn't just hurt us internally, it shows up in client conversations, in missed deadlines, in that low-grade anxiety before every push to production. We couldn't keep patching around the real problem.

So we migrated to Strapi + Next.js. Here's what actually happened.

What WordPress Was Actually Costing Us?

We didn't decide to redo our whole stack for fun. WordPress made the decision for us.

Performance was the first crack. Our Lighthouse score sat around 48 on mobile, and it didn't matter what we did. Add a caching plugin, score goes up a bit. Add an SEO tool, score drops again. We were playing whack-a-mole with a CMS that was never really built for the speed standards developers care about today.

Then came the security side of things. WordPress runs about 43% of all websites on the internet, which makes it the biggest target out there. We patched everything on time but patching often broke something else. Plugin A didn't work with the new WordPress version. Plugin B had its own vulnerability. Keeping the site secure started eating real hours every month.

Version control was the part that embarrassed us most. Our site lived in a database. There was no git revert rolling back meant restoring a database snapshot and hoping for the best. Two devs couldn't touch the site at the same time without running into each other.

The final straw: a staging-to-production sync went wrong and wiped three weeks of content. No clean rollback. No easy recovery. After that we stopped asking "should we migrate?" and just started figuring out how.

Why Headless CMS? Why Not Just a Better WordPress?

We looked at WP Engine, Kinsta, and a properly optimized WordPress setup before going further. These were real options, not just boxes we checked before doing what we'd already decided.

What stopped us: better hosting wouldn't fix the actual problem. WordPress is a monolithic app where the backend and frontend are stuck together. That works fine for a lot of sites. It didn't work for us anymore. We needed to deploy the frontend on its own, scale the content API separately, and have the whole thing live in version control like a normal codebase.

That's what going headless gives you. The CMS handles content. The frontend does what you need it to do. They talk through an API, and neither one cares what the other is built with.

We see this come up a lot whether you work at a small frontend development company or you're part of an in-house team. The moment your frontend needs start outpacing what a WordPress theme can handle, the monolithic setup starts getting in the way.

We chose Strapi because:

It's open-source, no per-seat pricing, no surprise invoices
Editors got comfortable with the content manager in about a day
The REST and GraphQL APIs are clean and well-documented
We could host it on the infrastructure we already had

Next.js handled the frontend. With Static Site Generation and ISR, pages build at deploy time and get served straight from a CDN edge. No PHP on every request. No database hit on every page load. Just fast, pre-built HTML.

What the Process of Migration Actually Looked Like?

We planned for three weeks. It took six. Here's what happened.

Content modeling came first: Before we wrote a single line of Next.js code, we spent a week mapping our WordPress structure to Strapi content types. Blog posts, authors, categories, media all of it needed a type definition. It's the least exciting part of the project, but if you rush it, you'll be untangling the mess for weeks afterward.

Then came the data move: We used WordPress's XML export to pull the raw content, then wrote a Node.js script to push each entry into Strapi through its API. Images were separate, we had to pull them from the WordPress media library and re-upload them to Strapi's storage. This step took longer than the content modeling. Don't underestimate it.

Building the Next.js frontend was the fun part: getStaticProps pulled data from Strapi at build time, and pages came out as pure static HTML. We added next/image for automatic image optimization that one change alone gave us a big chunk of our Lighthouse score back.

One thing we did not see coming: ISR is trickier than the docs make it look. We set revalidate: 60, which means any page can be up to 60 seconds out of date after a content change. Fine for a blog post. Not fine for our pricing page. We ended up wiring up on-demand revalidation, a Strapi webhook fires on publish and hits our /api/revalidate endpoint in Next.js. If you're doing this build, figure out your revalidation strategy before you go live. It's the thing most tutorials gloss over.

Six Months Later: The Actual Numbers

Lighthouse score (mobile): 48 → 94
Time to First Byte: ~1.8s → ~120ms (CDN edge, pre-built pages)
Security incidents: 3 in our last year on WordPress → 0 in six months on the new stack
Deployments: the team stopped dreading them

The version control win doesn't show up in any benchmark, but it might be the one we talk about most internally. The whole frontend lives in Git. Every change is reviewable. Rolling back is one command. Staging and production run from the same repo, so "works on staging" actually means something now.

The content team needed about two weeks to find their footing in Strapi after years of WordPress. The editor is different. The media library works differently. Give people time and don't act surprised when there's a learning curve there will be one.

Should You Do This?

Not everyone should. Here's the honest breakdown.

This Headless CMS makes sense if:

Your team has developers who know React and are fine fetching data from an API
Performance and control over the frontend matter more than convenience
You're constantly fighting WordPress's security issues or hitting its scaling limits
Your content is complex, or you need to push the same content to multiple platforms
You're a full-stack development company where engineers own the whole pipeline from backend to browser

Stick with WordPress if:

A non-technical team runs the content day-to-day and it's working fine
You don't have dev time to maintain a custom Node.js frontend
The plugin ecosystem is doing the job without constant maintenance headaches

Going headless means you own more of the stack. There's no plugin that handles everything anymore sometimes you just write the code. For some teams that's extra weight. For us it was a relief.

We'd make this call again. But it's not the right call for everyone, and I'm not going to pretend otherwise.