Forem: Lewis kori

Deploying a Next.js Monorepo to Cloudflare Workers: Lessons from the Trenches

Lewis kori — Tue, 07 Apr 2026 20:11:18 +0000

Earlier this year, I migrated my personal site from Netlify to Cloudflare Pages. The experience was smooth enough to get me thinking about what Cloudflare could do for a more demanding workload.

A real production monorepo. Multiple Next.js apps. Shared packages. Real users.

A few months later, that project is running entirely on Cloudflare Workers.

This post is the story of how we got there.

The Setup

The monorepo contains three Next.js 16 apps and a set of shared packages, all managed with Nx 22 and pnpm workspaces. Shared code, such as components, utilities, types, hooks, and config, lives in packages/ and is consumed by each app via TypeScript path aliases.

The apps range from a lightweight customer-facing site to a heavier dashboard with auth middleware, i18n, and Sentry.

We were deployed on Firebase Hosting with Cloud Functions and a custom GitHub Actions pipeline.

It worked.
Until it didn’t.

Why We Left Firebase

This was not a single decision. It was a slow accumulation of friction.

The CI/CD pipeline became a liability

We built a fairly complex GitHub Actions workflow to build and deploy each app independently of the monorepo. Over time, it became fragile. Deploys were flaky. Build ordering introduced hidden dependencies. Silent failures made debugging painful.

At some point, the pipeline stopped feeling like infrastructure and started feeling like something we had to constantly babysit.

And it was quietly burning through our GitHub Actions minutes.

Firebase's Next.js support had not kept up

Firebase Hosting’s native Next.js integration works reasonably well for older versions of the framework, but support for newer App Router features, React Server Components, and server actions is limited.

Every time we wanted to use something up-to-date, we had to check whether Firebase could handle it.

Usually, the answer was sort of, with caveats.

That is not a position you want to be in.

Cost unpredictability

Firebase pricing scales with function invocations, bandwidth, and compute. It is predictable at low traffic, but becomes harder to reason about as you grow.

For SSR workloads, it adds up faster than expected.

When I rebuilt my personal site on Cloudflare Pages, I got a glimpse of a simpler model.

Git-integrated builds.
Instant global propagation.
No operational overhead.

It felt calm.

I wanted that for production.

The real question was: could Cloudflare Workers handle a full SSR monorepo?

Enter @opennextjs/cloudflare

The piece that makes Next.js on Cloudflare Workers possible is @opennextjs/cloudflare.

It takes a Next.js build output and adapts it to run as a Cloudflare Worker.

The config is minimal:

// open-next.config.ts
import { defineCloudflareConfig } from "@opennextjs/cloudflare";

export default defineCloudflareConfig({});

Most of the real configuration lives in wrangler.jsonc:

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "main": ".open-next/worker.js",
  "name": "my-app",
  "compatibility_date": "2025-04-01",
  "compatibility_flags": [
    "nodejs_compat",
    "global_fetch_strictly_public"
  ],
  "assets": {
    "directory": ".open-next/assets",
    "binding": "ASSETS"
  },
  "services": [
    {
      "binding": "WORKER_SELF_REFERENCE",
      "service": "my-app"
    }
  ],
  "limits": {
    "cpu_ms": 30000
  },
  "vars": {
    "NEXT_BASE_URL": "https://api.example.com"
  }
}

Deploying from the monorepo root looks like this:

cd apps/my-app && npx opennextjs-cloudflare build && npx opennextjs-cloudflare deploy

We wrapped this in a Makefile, so the commands stay short and consistent across all apps.

Protecting Preview Deployments with Cloudflare Access

One of the easiest wins in this migration was using Cloudflare Zero Trust Access to protect non-production environments.

Previously, staging URLs were open to anyone who found them.

Not a disaster.
But not ideal.

With Cloudflare Access, you can gate any deployment behind identity. Email OTP, Google, GitHub, or any OIDC-compatible provider. No code changes required.

It sits in front of your Worker at the network level.

For us, staging environments now require authentication. Everyone else hits a login wall.

Setup took about ten minutes.

This is one of those features you do not realise you needed until you have it.

If you have not looked at Zero Trust Access for protecting internal tools or preview environments, it is worth a look. The free plan covers up to 50 users.

The Gotchas Nobody Warns You About

Every migration has sharp edges. These are the ones that cost us the most time.

1. `compatibility_date` and `process.env`

We centralise environment variable handling through a Zod schema that calls envSchema.parse(process.env) at startup.

On Cloudflare Workers, variables set in wrangler.jsonc or through the CLI do not automatically appear in process.env unless your compatibility_date is 2025-04-01 or later.

Before that date, the nodejs_compat_populate_process_env flag is not auto-enabled, and process.env is effectively empty at runtime. Your app boots, Zod parses an empty object, and everything breaks in a way that is not immediately obvious.

Set your compatibility_date to 2025-04-01 or higher from the start.

2. No `export const runtime = 'edge'`

If you have export const runtime = 'edge' in any route files, remove it.

@opennextjs/cloudflare does not support the edge runtime directive. The adapter handles the runtime itself.

3. Middleware cannot use `cookies()` from `next/headers`

The cookies() API from next/headers is Node.js only. If you are using it in middleware.ts for auth or session handling, it will not work on Workers.

Use req.cookies from NextRequest instead:

// Works on Workers
export async function middleware(req: NextRequest) {
  const token = req.cookies.get('access_token')?.value;
}

// Node.js only. Won't work in Workers middleware
import { cookies } from 'next/headers';

This is easy to miss because next dev runs fine locally. The break only surfaces when you run the actual Workers preview.

4. The 3 MiB free plan limit

Cloudflare’s free plan has a 3 MiB gzip limit per worker. For simple apps, this is fine. For anything with heavy dependencies such as Sentry server-side, complex auth libraries, or i18n, you will likely hit it.

The paid plan at $5 per month raises the limit to 10 MiB.

For apps close to the boundary, audit your server-side bundle. For us, Sentry server instrumentation was the biggest contributor. We stripped it from the lighter apps and kept only client-side Sentry there. The heavier dashboard stays on the paid plan.

Environment Variables and Secrets

Cloudflare has a clear three-tier model for environment variables, and it is worth understanding before you start:

Type	How to set	When available
`NEXT_PUBLIC_*`	`.env` file	Build time. Inlined into client bundles
Regular vars	`vars` block in `wrangler.jsonc`	Runtime. Accessible via `process.env` on the server
Secrets	`wrangler secret put` CLI	Runtime. Encrypted, accessible via `process.env`
Local dev vars	`.dev.vars` file (gitignored)	Local development only

For local development, create a .dev.vars file in each app directory:

# apps/my-app/.dev.vars
NEXTJS_ENV=development
NEXT_BASE_URL=https://staging.api.example.com
APP_API_KEY=your-dev-key-here

Wrangler reads this automatically during wrangler dev and wrangler preview. Add .dev.vars* to your .gitignore so staging variants are covered too.

Secrets for production:

cd apps/my-app
npx wrangler secret put APP_API_KEY
npx wrangler secret put APP_API_KEY --env staging

One thing we had to fix during the migration was our env schema. It had hardcoded .default() values for several secrets, leftovers from earlier development. We removed those and made optional secrets actually optional in Zod, with runtime guards in the server actions that use them:

export async function someAction() {
  const apiKey = env.APP_API_KEY;
  if (!apiKey) {
    return { error: 'APP_API_KEY is not configured' };
  }
  // ...
}

Setting Up Staging Environments

This part tripped us up more than expected.

Cloudflare Workers Builds, their git-integrated CI/CD, creates preview URLs for non-production branches. The catch is that preview URLs share the same environment variables as production. There is no way to override them per preview.

So if your staging environment points to a different backend, preview URLs are not enough.

The solution is wrangler environments. Add an env.staging block to your wrangler.jsonc:

{
  "name": "my-app",
  "vars": {
    "NEXT_BASE_URL": "https://api.example.com"
  },
  "env": {
    "staging": {
      "vars": {
        "NEXT_BASE_URL": "https://staging.api.example.com"
      },
      "services": [
        {
          "binding": "WORKER_SELF_REFERENCE",
          "service": "my-app-staging"
        }
      ]
    }
  }
}

This creates a separate my-app-staging worker.

Important: vars and services are non-inheritable keys in Wrangler. They do not cascade from the top-level config into your environments. You must fully specify them in each env block, or the staging worker starts with empty vars.

Deploying to staging:

cd apps/my-app && npx opennextjs-cloudflare build && npx wrangler deploy --env staging

For automated staging builds via the Cloudflare dashboard, connect the same repo to both the production and staging workers, with different deploy commands:

Production worker: npx wrangler deploy, watching your main branch
Staging worker: npx wrangler deploy --env staging, watching your staging branch

In monorepo setups, also set the root directory to the app’s folder and configure build watch paths to include packages/** so builds only trigger when relevant files change.

Cost Breakdown

Resource	Monthly cost
Small apps on free plan	$0
Dashboard app on Workers Paid	$5
Custom domains via Cloudflare DNS	$0
Total	$5

The free plan covers 100,000 requests per day, which is plenty for most apps. The paid plan gives you 10 million requests per month and the 10 MiB bundle limit the heavier dashboard needed.

For comparison, Vercel teams start at $20 per user per month. Firebase Cloud Functions pricing scales in ways that are harder to predict. At $5 per month for global edge delivery across all our apps, we are satisfied with where we landed.

Was It Worth It?

Yes. Unreservedly.

The deployment pipeline went from a custom, increasingly brittle GitHub Actions setup that chewed through CI minutes to a first-class, git-integrated workflow that just works.

Push to main, and the production worker updates. No YAML archaeology required.

Firebase’s Next.js limitations are gone. We can use anything current in Next.js 16 without checking whether the hosting layer can keep up.

The performance is genuinely better. Running at the edge in 300+ locations means users in Nairobi, Paris, and São Paulo all get fast responses, not just the ones nearest to a data centre we picked.

And the Cloudflare ecosystem is increasingly coherent. Workers, Pages, Access, DNS, R2. They work together in a way that makes the platform feel like an actual platform rather than a collection of services.

After running my personal site there for several months, and now production workloads, I have become a genuine believer.

If you are running a Next.js monorepo and your Firebase or Vercel setup is starting to feel like a liability, Cloudflare Workers is worth a serious look.

What We’re Looking Forward To: The Next.js Adapter API

One thing I am genuinely excited about as a next step is the official Next.js Adapter API, which shipped as stable in Next.js 16.2.

For a long time, deploying Next.js anywhere other than Vercel meant reverse-engineering the build output. @opennextjs/cloudflare was essentially a sophisticated workaround. It worked, but it was always playing catch-up with new framework features.

The Adapter API changes that.

It gives every platform the same contract: a typed, versioned description of the application, including routes, prerenders, static assets, runtime targets, and caching rules, that an adapter can consume and map onto its own infrastructure.

Crucially, Vercel’s own adapter is built on this same public API. No private hooks. No undocumented behaviour.

The Next.js Across Platforms blog post is worth reading for the broader context.

For Cloudflare specifically, a verified adapter built on this API is already in active development. Once it ships, the @opennextjs/cloudflare integration will sit on a stable, tested foundation that evolves with Next.js rather than chasing it.

For developers, that means first-class Next.js features such as Partial Prerendering, Cache Components, and on-demand revalidation should eventually work consistently on Cloudflare Workers, with upstream documentation and testing.

We are already on the platform. When the official adapter lands, migrating to it should be straightforward.

AI Is Not Your Intern. And That’s the Problem.

Lewis kori — Mon, 30 Mar 2026 15:02:23 +0000

When I first started using coding agents seriously, I made a familiar mistake.

I treated the model as the main thing.

I wrote better prompts. Then longer ones. Then, more carefully structured ones.

Sometimes it worked beautifully.

Sometimes it drifted.

Same repo. Same goal. Different result.

That inconsistency bothered me, because it revealed something deeper:

The bottleneck was not raw intelligence.

It was context.

In AI Is Not Replacing You. It’s Reshaping How You Think, I wrote about how AI shifts the bottleneck upward. When generation becomes cheap, the differentiator becomes judgment, constraints, and systems thinking.

That same pattern shows up in agentic engineering.

The real leverage does not come from asking a model to do more.

It comes from designing a better system around the model.

The Mistake I Kept Making

Early on, I was treating the agent like a very smart freelancer with amnesia.

I would drop it into a task, explain the problem, and expect one well-written instruction block to carry the entire interaction.

Sometimes it did.

But as soon as the work became real, things broke down.

Design fidelity mattered.

SEO mattered.

Content structure mattered.

Localisation mattered.

Existing conventions mattered.

Small decisions from earlier in the build mattered.

One prompt was never going to carry all of that.

That’s when it clicked:

Agentic engineering is not prompting.

It’s environment design.

On a recent workflow, I wasn’t asking an agent to “build a website.”

I was asking it to:

work inside a multilingual Astro codebase
preserve structured SEO
keep markdown content editable
support Arabic RTL layouts
respect project-specific rules already established
generate UI directions using Stitch
interact with external tools through MCP integrations

That’s not a prompt problem.

That’s a context problem.

And context has to be layered.

If the model is the engine, skills are the practised moves, MCPs are the ports to the outside world, and AGENTS.md is the field manual for the project.

Once I started seeing the stack this way, everything became more stable.

Skills Are Reusable Judgment

The clearest explanations of skills come from:

Anthropic’s Agent Skills Overview
Strapi: What Are Agent Skills
Agent Skills Format
skills.sh (a curated and security-conscious skill registry)

The idea is simple:

A skill packages repeatable expertise into something an agent can reuse.

That matters because prompts are temporary.

Skills are accumulated judgment.

Instead of re-explaining how to:

audit SEO
structure content
apply system constraints

…you encode it once.

Now every task starts from a higher baseline.

In practice, skills do three things:

reduce repetition
reduce drift
make quality portable

That last one is the real shift.

Without skills, success depends on remembering the right phrasing at the right time.

With skills, you turn one-off cleverness into infrastructure.

That’s leverage.

MCPs Give Agents Reach

If skills shape how an agent thinks, MCPs shape what it can do.

The Model Context Protocol is an open standard that connects models to external systems.

Models know patterns.

MCPs let them touch reality.

That reality includes:

repositories
APIs
documentation
browsers
design tools like Stitch
databases
internal tools

Without MCPs, an agent is reasoning in isolation.

With MCPs, it can:

observe
verify
act

That’s the difference between generating suggestions and executing work.

AGENTS.md Gives Agents Memory

The part most teams underestimate is memory.

That’s where AGENTS.md comes in.

The simplest way to think about it:

It’s a README for agents.

But unlike a typical README, it captures the operational reality of a project:

how the codebase behaves
Which commands are safe
what constraints must be respected
what has already been learned

In one of my workflows, this included things like:

why Tailwind must stay locally compiled
why English routes remain unprefixed
how RTL must be handled
what business details must remain consistent

Without this, the agent rediscovers the project every time.

With it, the agent starts from context.

This ties back to something I wrote in Why I Write:

Writing forces clarity.

Good documentation does the same thing for systems.

It turns implicit knowledge into something reusable.

The Agent Is Not the System

This is the part that matters most.

People talk about agentic engineering as if the intelligence lives entirely inside the agent.

It doesn’t.

The agent is just one layer.

What makes the system reliable is the composition:

the human provides intent and judgment
skills provide reusable expertise
MCPs provide access to reality
AGENTS.md provides memory
the agent executes within that structure

That’s the system.

Recently, I watched a talk by Jacob Bank (ex-Google, founder of Relay.app) that reinforced this perspective:

A few ideas stood out:

AI is not your intern
managing people becomes less central than designing systems
build one simple agent at a time
fire agents that don’t deliver
clarity of intent is everything
your personality becomes the differentiator

That framing aligns closely with what I’ve experienced.

The leverage doesn’t come from one powerful agent.

It comes from how well the system around it is designed.

That’s why I don’t think the future belongs to people who are just good at prompting.

It belongs to people who can design systems of context.

People who can decide:

what should be reusable
what should be connected
what should be constrained
what should remain human

In Building Better: Looking Back on 2025, I wrote about building better systems around my life and work.

This is the same instinct.

The goal isn’t to layer AI onto existing habits.

The goal is to redesign the workflow so intelligence has somewhere useful to go.

Agentic engineering is not the art of finding one perfect prompt.

It’s the discipline of building context architecture that makes good work more likely.

That’s where the leverage is.

That’s where the quality comes from.

And that’s where the real craft of this era is being built.

What I’m Exploring Next

This piece is part of a broader exploration into agentic systems.

Next, I’ll be diving deeper into:

Model Context Protocol (MCP) and how it actually works in practice
Designing skill libraries for real production workflows
How to structure agent-first systems in real applications

AI Is Not Replacing You. It’s Reshaping How You Think

Lewis kori — Wed, 18 Feb 2026 18:17:15 +0000

When AI started writing decent code, I did not feel excitement.

I felt unsettled.

Part of it was personal. I had built a career on being able to untangle complex systems, reason through architectural tradeoffs, and hold messy abstractions in my head until they became clear.

But part of it was practical.

If a model can scaffold refactors, generate tests, reason about edge cases, and produce solid patterns in seconds, then the question becomes unavoidable:

What happens to engineers when parts of their skill set become automated?

That fear is not irrational.

Teams are getting leaner. Productivity expectations are rising. Companies are under pressure to ship more with fewer people. AI is not a novelty anymore. It is embedded into workflows.

The work is changing in real time.

The Misunderstanding About AI

There are two extreme reactions to AI.

One camp believes it will replace human engineers entirely.
The other dismisses it as glorified autocomplete.

Both miss something important.

AI does not think like a human. It does not understand systems in the experiential sense. It does not care about uptime, team velocity, or long-term maintainability.

It predicts patterns.

And prediction at scale can look remarkably competent.

But prediction is not judgment.

That distinction is critical.

The Real Fear: Economics and Value

The anxiety around AI usually blends two concerns.

The first is economic.
Will this reduce demand for engineers?

The second is personal.
Will this reduce the value of what I bring?

AI absolutely compresses certain types of work. Boilerplate generation, repetitive refactors, scaffolding, and documentation drafts. The cost of iteration is dropping fast.

But that does not eliminate engineering.

It shifts the bottleneck.

When code generation becomes easier, the constraint moves to:

Architecture decisions
Systems integration
Tradeoff analysis
Failure modeling
Product alignment
Accountability

The floor lowers.

The ceiling rises.

Engineers who compete only on raw output will struggle.

Engineers who operate at the level of systems and constraints will gain leverage.

The Turning Point in My Workflow

The shift for me happened when I stopped using AI as a replacement and started using it as a thinking partner.

Instead of asking it to “write this feature,” I began asking it to stress test my ideas.

I would describe a multitenant billing system with evolving discount rules and ask it to critique the domain model. I would have it enumerate failure modes in webhook handling, idempotency guarantees, and concurrency boundaries. I would ask it to propose alternative abstractions and then interrogate them.

Suddenly, it was not competing with me.

It was expanding my cognitive bandwidth.

Instead of spending an hour drafting a single architecture direction, I could explore multiple viable approaches quickly and focus on the harder question:

Which one survives contact with reality?

My job became less about producing code from scratch and more about defining constraints, filtering options, and owning decisions.

That is higher leverage work.

Reading AI 2041 Put This in Context

While navigating this shift, I started reading AI 2041: Ten Visions for Our Future by Kai-Fu Lee and Chen Qiufan.

The book pairs speculative stories set in 2041 with grounded technical analysis of where AI is realistically heading. It does not frame AI as magic. It frames it as infrastructure.

In one story, AI assistants optimise daily decisions so effectively that they begin shaping behaviour itself. In another, hyper-realistic synthetic media challenges society’s ability to distinguish truth from fabrication. Other chapters explore personalised AI education, autonomous systems, and algorithmic governance.

The consistent pattern is this:

AI expands capability.
Humans remain accountable.

The systems amplify us. They do not originate purpose.

That mirrors what I see in engineering. AI can generate options. It cannot decide what is aligned with the product vision, the business model, or long-term technical health.

Those decisions remain human.

The AI Stack I’m Using

This shift is not abstract. It is operational.

Here are the tools currently shaping how I work.

GitHub Copilot Pro+

GitHub Copilot Pro+ lives directly in my editor. It handles low-level friction extremely well. Boilerplate, repetitive patterns, test scaffolding, and interface implementations. It uses local context to generate code that aligns with the file and project structure.

The fundamental benefit is cognitive offloading.

Instead of spending working memory on syntactic repetition, I stay focused on architecture and intent. Copilot accelerates expression. It does not replace direction.

Variant

Variant is closer to an AI-native website design tool than a coding assistant. Conceptually, it sits nearer to design platforms like Figma make or emerging AI-enhanced layout builders.

Instead of focusing on implementation details, Variant accelerates layout generation, design system consistency, and structured UI exploration.

For engineers who touch frontend systems, this matters.

It shortens the loop between concept and visual artefact. Instead of manually iterating on layout structures or styling hierarchies, AI can generate structured starting points that you refine.

This shifts attention from pixel pushing to experience reasoning.

ChatGPT Codex

ChatGPT Codex is where I go for higher-level reasoning.

When I need to explore design tradeoffs, simulate adversarial critiques, or prototype alternative abstractions, this is the thinking layer.

I use it to:

Stress test system boundaries
Model edge case behaviour
Generate multiple architecture directions quickly
Challenge assumptions before implementation

The fundamental benefit is parallel cognition.

It feels less like delegation and more like expanding thought capacity. I remain accountable. But I am no longer thinking alone.

The Real Difference Between Humans and AI

AI responds to framed problems.

Humans decide which problems matter.

AI can expand the solution space. It can generate variations at scale. It can surface blind spots.

It cannot choose meaning.
It cannot care about consequences.
It cannot take responsibility when systems fail.

Engineering is not just code generation.

It is ownership.

That part is not automated.

Where This Is Headed

AI will continue compressing certain tasks.

Entry-level work will change. Expectations for productivity will rise. Teams will likely stay leaner.

But the demand for people who can define systems, reason about complexity, and own outcomes is not disappearing.

If anything, it becomes more valuable.

The engineers who thrive will not be the fastest typists.

They will be the ones who:

Define the right problems
Set clear constraints
Interrogate AI outputs critically
Integrate tools into disciplined workflows
Take responsibility for results

AI is not replacing engineers entirely.

It is reshaping engineering.

The work becomes less about proving you can produce code alone and more about orchestrating intelligence effectively.

That is not a downgrade.

It is a shift in leverage.

And the sooner we adapt to that reality, the better positioned we will be in the decade ahead.

From Gridsome to Astro: Rebuilding My Personal Site for the Next Phase

Lewis kori — Fri, 23 Jan 2026 19:42:14 +0000

Six years ago, I rebuilt my personal website using Gridsome and Vue.js. At the time, it felt modern, fast, and perfectly aligned with how I wanted to publish technical writing.

That rebuild became this article:

👉 Building my new site with Gridsome & Vue.js

Fast forward to today, that same site still exists at lewiskori.netlify.app, but it had started to feel like a time capsule. The tooling had aged, the ecosystem had slowed down, and more importantly, my own work and interests had expanded far beyond what the site was originally designed to represent.

So I decided to rebuild again.

This time with Astro, hosted on Cloudflare Pages, with a stronger content model, better performance, and a structure that reflects where I am today as an engineer and advisor.

This post is about why I made that move, what changed, and what I learned along the way.

Why Move Away from Gridsome?

To be clear, Gridsome served me well. It gave me:

Static site generation with Vue
Markdown-based content
A smooth authoring experience for the time

But today:

The ecosystem is largely inactive
Plugin maintenance has slowed significantly
Modern web tooling has moved on

In short, it became harder to evolve the site than to rebuild it.

For a personal site that I actually want to use as a thinking space, that is not a good place to be.

Why Astro Felt Like the Right Fit

Astro hit a very specific sweet spot for what I wanted:

Content-first architecture (Markdown, MDX, collections)
Minimal client-side JavaScript by default
Framework-agnostic components when needed
Excellent performance out of the box

But more than features, Astro feels aligned with how the web is trending again:

static where possible, dynamic only where necessary.

That matches how I write and publish. Most of my content does not need hydration, interactivity, or heavy client logic.

It just needs to load instantly and read well.

Multiple Themes: Light, Dark, and Sepia

One of the things I really wanted in this rebuild was intentional reading modes.

The new site supports:

Light mode
Dark mode
Sepia mode (surprisingly great for long-form reading)

Theme preference is persisted, and switching is instant.

This seems like a small detail, but it changes how comfortable long sessions on the site feel, especially for essays and technical deep dives.

A Broader Representation of My Work

Previously, the site was mostly:

Blog posts
A simple “About” section

That no longer reflects what I actually do.

The new structure includes:

Advisory – work with startups and private equity-backed firms
Projects – long-running technical efforts and experiments
Resources – books I am reading, tools I use, desk setup, and stack
Operating Notes – practical reflections on building companies and systems

This was intentional.

I wanted the site to capture not just what I build, but how I think about building.

Better Content Discovery: Series and Tags

As my writing has improved, so has the structure of my content.

Now:

Posts can belong to series
Tags are actually useful for navigation
Related content is easier to surface

This makes the site more usable for:

New readers
People landing from search
Anyone following a specific topic

It also forces me to be more disciplined about how I publish.

Moving from Netlify to Cloudflare Pages

This move was both practical and strategic.

Practically:

GitHub-based CI/CD is still there
Builds are fast
Edge delivery is excellent

Strategically:

Cloudflare has acquired Astro, which gives me far more confidence in:

Long-term platform stability
Investment in performance tooling
Tight integration with edge services

It is rare to see hosting, CDN, and framework alignment at this level, and it made the decision straightforward.

Performance: Actually, Genuinely Fast

Astro already helps here, but I was deliberate about:

Zero unnecessary hydration
Minimal client-side scripts
Aggressive static generation

The result is a site that is, frankly, boring in how fast it loads. Which is exactly what I want.

The Lighthouse test scores speak for themselves

Performance is consistently near perfect
No layout shift
Immediate content paint

This matters not just for SEO but also for reading comfort.

Newsletter Support with Beehiiv

Writing is something I am taking seriously again.

The new site integrates directly with Beehiiv for newsletter subscriptions, which allows me to:

Publish long-form essays
Reach readers outside of social platforms
Own the distribution channel

This also aligns with my decision over the last year to step away from algorithm-driven platforms and focus on slower, more intentional publishing.

Open Sourcing the Entire Codebase

This part matters to me.

The full site is now open source.

Not because the code is groundbreaking, but because:

Personal sites are great learning material
People often ask how certain layouts or systems work
Transparency aligns with how I learned early in my career

If something in the site helps another developer ship their own, that is a win.

The Open Source Code is available on my Github

And a special thank you to Evans Robbie for all the help with the frontend styling.

What This Rebuild Actually Represents

On the surface, this is a framework migration.

In reality, it reflects something deeper:

I write differently now
I work across engineering, business, and strategy
I care more about clarity than cleverness

This site is not just a portfolio anymore.

It is an operating system for how I think, learn, and share.

Astro just happened to be the best tool to support that.

What’s Next

Now that the foundation feels solid, the focus shifts to:

Writing more consistently
Publishing deeper technical and business essays
Sharing practical experiences from advisory and operating work

The stack is finally out of the way.

Now the real work, the thinking and the writing, can take centre stage again.

If you are curious, the previous version of the site still lives here:

👉 https://lewiskori.netlify.app

And the new one is live at:

👉 https://lewiskori.com

Here is to rebuilding, again, but this time with much clearer intent.

Smarter Apps with PostHog: Feature Flags & Analytics

Lewis kori — Thu, 11 Sep 2025 12:52:20 +0000

Building an app, whether it's a quick side project or a full-fledged SaaS solution, is an exciting adventure. You eagerly ship a new feature, hoping for enthusiastic feedback, but often find yourself waiting in silence. The reality is, without clear insights, we often fly blind. We move fast, but sometimes we end up going in circles.

That's where analytics and feature flags come in. They aren't just for the major players anymore. These tools are essential for understanding what's working, what's not, and how users are truly engaging with your product.

Why Django Developers Should Care

As a Django developer, I love the "batteries-included" philosophy. It lets us build robust, secure backends at incredible speed. But when it comes to product-led growth—understanding user behaviour, rolling out features safely, and running experiments—we often have to piece together solutions. Integrating separate analytics packages, building a feature toggle system from scratch... it can feel like a puzzle.

This is why I've been so impressed with PostHog. It’s a platform built for product engineers that combines analytics, feature flags, and session replay into a single, cohesive solution. For a Django developer, this means you can spend less time integrating tools and more time building what matters, backed by real data.

Let’s dive into how PostHog can make your Django app smarter, safer and more data-driven.

Pre-requisites

Before following along, make sure you have the basics in place:

Python 3.10+ and Django 4.0+ (the examples assume a modern Django stack).
A working multi-tenant setup (e.g. using django-tenants or a similar package), since group identification is demonstrated with request.tenant. - Optional
An existing PostHog account with a project API key. You can sign up for free at posthog.com.
Familiarity with Django middleware and how to add custom classes to the MIDDLEWARE list.
Optional but recommended: Docker if you prefer to self-host PostHog instead of using their cloud service.

With these in place, you’ll be able to plug in PostHog confidently and follow every step without hitting blockers.

Getting Started: A Production-Ready Setup

Before you can use feature flags or track events, you need to get PostHog configured. Instead of using global variables, let's build a robust, singleton client and a context-aware middleware. This pattern is safer for concurrent requests and much easier to manage.

Step 1: Install the Library
First, add the official Python library to your project:

pip install posthog

Step 2: Configure Your settings.py
Add your PostHog API key to your Django settings. It's best practice to load this from an environment variable.

# in settings.py
POSTHOG_API_KEY = env("POSTHOG_API_KEY", default=None)
POSTHOG_HOST = env("POSTHOG_HOST", default="https://app.posthog.com")
POSTHOG_ENABLED = env("POSTHOG_ENABLED", default=True)

Step 3: Create a Centralised PostHog Client
This is the core of a robust integration. A singleton client encapsulates the setup logic and ensures the client is initialised only once for your entire application. Create a new file for it.

# In a new file, e.g., myapp/integrations/posthog_client.py
import logging

import posthog
from django.conf import settings

logger = logging.getLogger(__name__)

class PostHogClient:
    """
    A singleton client for PostHog to provide a central, configured
    instance for the entire application.
    """
    _instance = None

    def __new__(cls):
        if cls._instance is None:
            cls._instance = super(PostHogClient, cls).__new__(cls)
            api_key = getattr(settings, "POSTHOG_API_KEY", None)
            if not api_key:
                logger.warning("POSTHOG_API_KEY not found. PostHog will be disabled.")
                cls._instance.client = None
            else:
                cls._instance.client = posthog.Client(
                    project_api_key=api_key,
                    host=getattr(settings, "POSTHOG_HOST", "https://app.posthog.com"),
                )
        return cls._instance

    def is_feature_enabled(self, feature_name: str, user, group=None) -> bool:
        if not self.client:
            return False

        groups = {"organization": str(group.id)} if group else {}
        group_properties = {"organization": {"name": group.name, "plan": group.plan}} if group else {}

        try:
            return self.client.feature_enabled(
                key=feature_name,
                distinct_id=str(user.id),
                groups=groups,
                group_properties=group_properties
            )
        except Exception as e:
            logger.error(f"Failed to check PostHog feature flag '{feature_name}': {e}")
            return False

# Create the shared singleton instance for your project to import
posthog_client = PostHogClient()

Step 4: Create the Identification Middleware
For PostHog to work correctly, it needs to know who the user is on every request. This middleware uses our new client and wraps each request in a new_context to ensure user data doesn't leak between concurrent requests.

# In a new file, e.g., myapp/integrations/posthog_middleware.py
from .posthog_client import posthog_client

class PostHogMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
        self.client = posthog_client.client

    def __call__(self, request):
        if not self.client:
            return self.get_response(request)

        # Use a new context for each request to ensure thread-safety
        with self.client.new_context():
            if hasattr(request, "user") and request.user.is_authenticated:
                user = request.user
                organization = getattr(request, "tenant", None)

                self.client.set(
                    distinct_id=str(user.id),
                    properties={'email': user.email, 'name': user.get_full_name()}
                )
                # Optionally attach group (e.g., tenant/organization)
                if organization:
                    self.client.group_identify(
                        group_type="organization",
                        group_key=str(organization.id),
                        properties={'name': organization.name, 'plan': organization.plan}
                    )

            response = self.get_response(request)
        return response

Step 5: Activate the Middleware
Finally, add the middleware to your settings.py. It must come after Django's AuthenticationMiddleware.

# in settings.py
MIDDLEWARE = [
    # ... other middleware ...
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'myapp.integrations.posthog_middleware.PostHogMiddleware',
    # ... other middleware ...
]

With this setup complete, your integration is now robust, safe, and ready for advanced use cases.

Use Case 1: Rolling Out Features with Smarter Feature Flags

While you can target individual users, the real power in a SaaS app comes from targeting groups.

The Pro-Level Use Case: Gating Features by Subscription Plan

Imagine you have different plans (BASIC, PRO) and want to give a company on the BASIC plan a free trial of a PRO feature.

Step 1: The Centralised Feature Checker

Create a central function that first checks your app's internal logic (the plan) and then asks PostHog for any overrides.

# In a central permissions.py file
from .integrations.posthog_client import posthog_client

FEATURE_AI_SEARCH = "ai_search"
PLAN_FEATURES = {"BASIC": set(), "PRO": {FEATURE_AI_SEARCH}}

def has_feature_access(organization, user, feature_name: str) -> bool:
    # 1. Check the plan first (fast, local check)
    if feature_name in PLAN_FEATURES.get(organization.plan, set()):
        return True
    # 2. If not, ask PostHog for an override using our client.
    return posthog_client.is_feature_enabled(feature_name, user, group=organization)

Step 2: Protecting Your Views

Now, you can protect your views cleanly using a custom mixin.

from .permissions import has_feature_access, FEATURE_AI_SEARCH

class FeatureFlagMixin:
    feature_name = None
    def dispatch(self, request, *args, **kwargs):
        if self.feature_name:
            if not has_feature_access(request.tenant, request.user, self.feature_name):
                raise PermissionDenied("This feature is not enabled for your account.")
        return super().dispatch(request, *args, **kwargs)

class AiSearchView(FeatureFlagMixin, TemplateView):
    feature_name = FEATURE_AI_SEARCH
    template_name = "ai_search.html"

This pattern lets you manage base permissions with your subscription plans and use PostHog to dynamically grant trial access, driving upgrades.

Use Case 2: Understanding Behavior with Proper Identification

The middleware we set up handles identification automatically, ensuring every event is correctly associated with the user and their organization.

When you capture a custom event from the backend, it's now context-aware:

# In a view, after a user uploads an article
posthog_client.client.capture(
    distinct_id=request.user.id,
    event='article_listed', 
    properties={'article_id': new_article.id, 'category': new_article.category.name},
    groups={'organization': str(request.tenant.id)}
)

Bonus: Session Replay

Want to see exactly how users interact with your app? Enable session replay in PostHog. Watching real user sessions is one of the fastest ways to find UI bugs and UX friction points—it’s like looking over your user's shoulder.

Best Practices & Lessons Learned

Think in Groups, Not Just Users: For any SaaS or multi-tenant app, group analytics are more powerful than user analytics. Always identify the company, team or organization the user belongs to.
Centralise Your Logic: Don't sprinkle PostHog calls all over your codebase. Create a central client singleton and use middleware for identification.
Keep Flags Tidy: Feature flags are powerful but can become technical debt. Regularly review and remove flags for features that are fully rolled out.

Conclusion: The Swiss Army Knife for Django Product Teams

With PostHog, you’re not just tracking clicks—you’re building a feedback loop. Feature flags de-risk your deployments, analytics tell you what’s working, and session replay shows you the "why" behind the numbers. For Django developers looking to build smarter, safer, and more responsive applications, it's an essential tool. You can finally ship, learn and improve—without flying blind.

What Makes a Good Website? Lessons From the Edge

Lewis kori — Tue, 26 Aug 2025 16:03:36 +0000

Over the past few years, I’ve had the privilege of working across fintech, blockchain, healthcare, and a variety of ambitious ventures through my consultancy work and Inflection Studio. Somewhere along the way, I started to notice a pattern. Projects that thrived weren’t always the ones with the biggest budgets or flashiest designs. They were the ones that got the fundamentals right.

This post is an attempt to capture those lessons. Not as “best practices” in the abstract, but as principles I’ve seen play out in the wild. Consider this my working definition of what makes a good website.

1. Clarity Before Cleverness

A good website doesn’t confuse you. The value proposition is clear from the first glance. You know what the business is about, who it’s for, and what to do next.

Too many projects get caught up in aesthetics, burying the message under animations, gradients, and jargon. I’ve been guilty of this too. At Inflection Studio, we’ve learned to strip it back. Design should guide, not distract.

Test: If a stranger can’t explain what your site does after 10 seconds, you’ve missed the mark.

2. Speed is Strategy

Nobody waits for a slow site. Performance is the invisible handshake between your product and the user. It communicates professionalism, care, and respect for their time.

We’ve adopted the principle that performance is design. It shapes everything from tech stack decisions (Next.js, caching, CDNs) to how we think about content delivery.

Test: If your site feels instant, you’re not just winning on UX — you’re improving SEO, conversions, and user trust.

3. Responsive by Default

This isn’t 2010. Your site isn’t being viewed only on a desktop monitor in a quiet office. It’s being pulled up on the go, in poor lighting, on shaky networks.

At Inflection Studio, we design for the smallest screen first. This isn’t just mobile responsiveness — it’s about empathy. Meeting users where they are, not where it’s convenient for us.

Test: If your mobile experience feels like an afterthought, the site isn’t done yet.

4. Brand as Experience

A logo and color palette don’t make a brand. The real test is whether a website feels like an extension of the company’s voice and ethos.

I’ve seen projects where the site looked good but felt hollow — like a template with someone else’s clothes. What sticks is consistency: visuals, copy, interactions, all reinforcing the same story.

Test: If you stripped the logo off your site, would people still recognize it as yours?

5. Measurement Over Myth

Here’s a hard truth: what feels like a “beautiful” website to you might be irrelevant to users. That’s why measurement matters.

Tools like PostHog, Microsoft Clarity and Google Analytics give us a window into reality. We’ve built a discipline around tracking what success looks like — not just visits, but engagement, conversions, drop-offs. It keeps us honest.

Test: If you can’t point to a metric that validates a design choice, it’s just opinion.

6. Evolution, Not Perfection

The best websites aren’t “launched” — they’re alive. They adapt as the business grows, as customers shift, as technology changes.

This is why at Inflection Studio we design systems, not just sites. Modular content structures, scalable design languages, and workflows that make iteration easy.

Test: If updating your site feels like starting from scratch, it wasn’t designed to last.

Final Thought

A “good website” is less about aesthetics and more about alignment. Alignment between what you say and what users need. Between the technology and the business model. Between ambition and execution.

These are lessons I’m still refining in my consultancy and through the work we do at Inflection Studio. And if there’s one thing I’ve learned, it’s this: a website is never really finished. It’s a living reflection of the business — and when it’s done right, it doesn’t just tell your story. It moves it forward.

Execution Is the Real Differentiator — and the Multiplier

Lewis kori — Tue, 26 Aug 2025 16:00:05 +0000

People talk a lot about big ideas, but the thing that actually changes outcomes is much smaller: showing up when you said you would. Whether it’s a 6 a.m. run or a product launch, execution is what earns trust and trust is what compounds.

A few months ago, I invested in a gym. One of my goals was to build a sense of community, so we started a Saturday morning running club. Six a.m., every week.

I’ve been a runner for years, but lately I’d been letting “too tired” and “too busy” win. The running club changed that. When you’ve promised people you’ll be there, you show up — even if your bed feels like it has diplomatic immunity. And when you do, you realise the showing up is the work. The enthusiasm fluctuates, sure, but that’s part of the game. Week by week, more people join. The momentum builds.

That same principle is at the core of my work as a software engineer. In tech, execution isn’t just about ticking boxes. It’s about delivering on what you said you would, because trust is currency. And when things don’t go to plan (which they won’t, often spectacularly), the next best thing to delivering is communicating early. Silence erodes trust faster than failure.

In both running and work, follow-through compounds. Each time you do what you said you’d do — or own up when you can’t — you build a reputation that opens doors. That reputation doesn’t come from big heroic sprints. It comes from the quiet, boring, unglamorous act of showing up.

The Saturday club has reclaimed my weekends. It’s also reminded me that whether you’re trying to run five kilometres or ship a feature, success multiplies when you close the gap between what you promise and what you deliver.

The Quiet Power of Starting From Scratch

Lewis kori — Mon, 16 Jun 2025 11:30:00 +0000

A few Sundays ago, I found myself on the rooftop of a mall restaurant, catching up with friends over a lazy lunch. As we laughed and lingered, my attention kept drifting to an elderly man seated alone a few tables away. He wasn’t eating—he was sketching. Head bowed slightly, pen gliding over paper with a quiet confidence, he was fully immersed in his work.

Curiosity got the better of me. After my meal, I walked over and introduced myself. I told him I used to draw and that I’ve recently been trying to rediscover that part of myself. He smiled and told me he only started drawing four years ago—self-taught through YouTube. What started as curiosity became a daily practice, nudged by online art communities. Now, he keeps a visual diary: drawings and notes documenting his travels and thoughts, all created for his daughter to someday read.

What struck me most wasn’t the beauty of his sketches (though they were beautiful). It was his boldness to begin something new at his age, without shame or hesitation.

That stuck with me. Because I believe one of the most underrated superpowers in life is the willingness to look foolish when you're starting out.

I work in tech, where nothing stands still. Tools change. Frameworks evolve. Entire paradigms shift overnight. You fall behind if you’re too proud to ask questions or afraid to look like a beginner. The people I admire most in this space are the ones who keep learning—who dive into new challenges headfirst, even if they’re clumsy at first.

That’s been my approach too. Whether it’s exploring new tools, starting a creative hobby, or just asking “dumb” questions in a meeting, I’ve learned to lean into the discomfort of not knowing. Because on the other side of that discomfort is growth.

So here’s to starting small, to asking questions, and to not pretending you have it all figured out. Whether you’re writing your first line of code or sketching your first tree, stay curious. Stay a beginner.

It’s how we move forward.

Why I Haven’t Blogged in Years (and How I’m Overcoming the Fear)

Lewis kori — Sun, 23 Mar 2025 12:00:00 +0000

It’s been over three years since I last wrote on my engineering blog. Three years of growth, new experiences, and lessons learned, but also three years of silence. Not because I had nothing to say but because every time I thought about writing, an invisible wall of anxiety and self-doubt stopped me.

I’ve grown greatly as an engineer. Tackling big projects, learning new technologies, and advancing in my career, but putting those learnings into words? That felt terrifying. I want to share why I’ve been so reluctant to write, in the hope that being open about it will resonate with others who face the same hesitations. This is a raw look at the mix of imposter syndrome, fear of failure, and perfectionism that held me back, and how I’m finally learning to move past these blocks. By reflecting on this struggle and the psychology behind it, I hope to reclaim my voice and help you do the same if you’ve felt similarly stuck.

Imposter Syndrome: The Voice That Says “You’re Not Enough”

Impostor syndrome — doubting your abilities to the point where you feel like a fraud — has been my constant companion whenever I considered blogging. Despite my accomplishments, I’d hear a nagging voice: "What right do I have to write about this? Surely everyone else knows this stuff. Someone more qualified should be doing this, not me."

I’m not alone in this feeling. In fact, 88% of developers said they’ve experienced imposter syndrome, including many with 10+ years of experience. Psychologists define imposter syndrome as an internalized fear of being exposed as a “fraud” despite evidence of your success. It often leads you to attribute your achievements to luck or others, and to downplay your expertise.

The irony is that I was robbing myself of the chance to contribute by giving in to these thoughts. I’ve learned that almost everyone who creates something faces this imposter voice at some point. Realizing how common these feelings are has been a crucial first step in stopping believing my imposter's voice.

Fear of Failure and Judgment: When Sharing Feels Risky

Closely tied to imposter syndrome was a fear of failure and being judged. Hitting “Publish” on a blog post felt like standing on a stage in a spotlight, inviting the world to critique me. What if I explained something wrong and got called out? What if my ideas were dismissed or ridiculed?

The fear of negative feedback or public mistakes can be paralyzing. Psychologically, this is rooted in a very normal desire to be accepted and competent. We dread doing something that might make others lose respect for us.

I felt this as a fear of visibility: I couldn't hide my imperfections if I put my thoughts out there. Over time, I’ve learned that most readers are not sitting there waiting to pounce on my mistakes. Many are probably appreciative of finding honest, human voices. And those who would judge harshly? They’re often not in the arena themselves.

The Perfectionism Trap: Waiting for the “Perfect” Post

Perhaps the most sneaky barrier of all has been perfectionism. I convinced myself that if I was going to write at all, it had to be flawless. In theory, having high standards sounds like a good thing. In reality, my perfectionism became a clever form of procrastination.

I would start drafts and then abandon them because they weren’t turning out as comprehensive or insightful as I imagined. I’d endlessly tweak wording, research extra details, or plan huge multi-part tutorials that I never finished. I was waiting for the perfect idea, the perfect mood, the perfect phrasing and as a result, I posted nothing at all.

Over time I learned an important truth: perfectionism is often a fear of failure in disguise. I’ve started to break this trap by embracing the mantra “done is better than perfect.”

Realizing I’m Not Alone (and Neither Are You)

For a long time, I thought my reluctance to write was a personal quirk or weakness. But I’ve since learned these feelings are extremely common, especially in the tech community. Knowing this has made a huge difference.

Hearing others open up about their fears has been inspiring and instructive for me. One developer wrote candidly: “I rarely blog about technical topics... The prospect has always scared me,” listing thoughts like “major case of Imposter Syndrome” and “What if I’m wrong?!” Her solution was to confront those fears by setting a modest goal (one blog post a month) and adopting a growth mindset.

That reframed writing from a performance to an act of service. Similarly, another engineer admitted he didn’t feel “qualified” to write tutorials until he realized that teaching others also reinforced his own knowledge — the fastest way to learn is in public. These insights started chipping away at the pedestal I’d put writing on.

It doesn’t have to be perfect or completely original; it just has to be useful or authentic.

How I’m Starting to Write Again: Mindset Shifts

Identifying these mental blocks is important, but the real question is: how do we move past them? Here are a few shifts that have helped me:

Embrace continuous learning: You don’t need to be an expert. Share what you’re learning as you go.
Remember the value of your perspective: Your unique experience matters and your way of explaining something might help someone else.
Shift from performance to service: Focus on helping just one person.
Accept imperfection as the price of growth: “B+” work shared is more impactful than “A+” work never published.

Strategies for Consistent, Fearless Writing

Some practical tips that I’ve started using:

Start small: Set a manageable writing cadence (e.g., one short monthly post).
Keep an idea list: Capture even the smallest insights or bugs you solved.
Time-box writing: Separate drafting from editing to reduce overthinking.
Use templates or frameworks: Scaffolding makes writing easier.
Share drafts with friends: Safe feedback helps you feel supported.
Celebrate small wins: Reward yourself for hitting "Publish."
Reconnect with your “why” regularly: Remember why you wanted to share in the first place.

Conclusion: From Self-Doubt to Sharing

Writing this post is my way of breaking a 3 years-long silence. By understanding the psychology behind my imposter syndrome, fear of failure, and perfectionism, I’ve begun to take away their power.

No, I haven’t vanquished my self-doubt completely, and maybe I never will, but I’m learning to act despite it. Each new post I share is a step toward reclaiming my confidence and authentic voice.

If you’ve struggled with similar blocks, know you’re not alone. Your insights have value. The community benefits when more real, diverse voices contribute. I’m finally adding mine, and I hope you’ll add yours too.

After all, the second best time to start writing is right now.

Tools to supercharge work productivity

Lewis kori — Mon, 21 Mar 2022 16:39:22 +0000

Freelancing is becoming a popular trend in the modern work environment. A lot of people go into freelance expecting smooth sailing. The dream is to choose their projects and do what they love when they want to. Unshackled from bureaucratic corporations. That’s the whole point of freelancing right? Well true, but in a lot of ways, it’s like starting your own business. This brings a raft of challenges and nobody prepares you for the multitude of admin tasks ahead. If not careful, this can hinder you from focusing on what you love and consequently, interfere with your productivity.

Keeping organized, staying on top of deadlines, bringing new clients, creating contracts, and chasing invoices to ensure that you get paid on time are just some of the things that you have to do by yourself. Fortunately, there’s a wide range of digital tools to help you complete these important tasks with ease. I work as a software engineer in fintech and here are some game-changers for me when it comes to performance, dedication, and smart use of work time.

Bonsai: Contracts and Invoicing

Bonsai is an all-in-one tool for digital freelancers and self-employed professionals to manage their work and money. Bonsai has everything you need, from proposals and contracts to invoicing and online payments to client CRM and forms to accounting and tax tools. Since everything is in one app, you can save time and money and stay even more organized.

One thing I really like with Bonsai is the seamless integration with contracts and invoices. With this, clients are sent invoices automatically with regular payment reminders. You can connect this with a payment processor of your choice such as stripe, PayPal and their platform will automatically flag an invoice as paid and stop the reminders.

Some other benefits I’ve got from Bonsai are:

Keeping organized by keeping all my projects in one place.
Time-saving as I can utilize their beautiful and intuitive proposal maker.
Built a professional image due to the seamless and easy integration between bonsai apps.

If this sounds appealing to you, they have a 14-day free trial and two other plans. Workflow for $19 per month which should suffice for most individuals and workflow plus for $29 per month. Should you decide to give Bonsai a trial, sign up using my referral link to support my work.

Wise: Payments

Wise, formerly Transferwise, is an international money transfer service. Wise has been a true game-changer in cross-border money transfer and I cannot recommend it enough. Wise essentially allows you to have a bank account in your client’s country and they can easily send money to that account as they normally would to any other local account. Once you have these funds in your wise account, you can easily convert that balance to your local currency and deposit it into your local bank account. Their exchange rate(a mid-market rate) is often better than the bank’s exchange rate so you get your funds at a premium 😃.

Receiving funds is free as of now so you should receive the entire amount in your invoices. They make money by taking a small percentage of the transaction from the sender.

Using my invite link to join wise, you’ll get a free transfer of up to 500 GBP! How awesome is that?

Grammarly: Checking writing errors

It should come as no surprise that in business, you need impeccable communication skills. Having well-crafted sentences with minimal errors can do wonders for your brand. No matter how much of a pro you are, we all make mistakes and that’s where Grammarly comes in. I use this tool to scan my writing for grammatical errors and tonal inference; emails, blog posts. Almost everything! They have a browser extension compatible with almost all popular browsers. The best thing is that their free plan is enough for most people!

Reclaim: Time management and scheduling

Reclaim is a smart calendar assistant that uses flexible time blocking for your calendar to make time for your important priorities, routines and tasks. If you’re competing with 50–60% of your calendar being taken up by meetings, or if you’re constantly having to context switch from one thing to another throughout the day, Reclaim is for you.

With reclaim, I can easily sync my work and personal calendar to avoid overbookings. One thing I really use this for is my workout time and lunch breaks. With reclaim, I can set these as high priority so anyone trying to book my time within those time blocks gets instantly notified that they’d have to reschedule. Their AI is smart enough to auto-schedule my low priority tasks to a later free time-block should anyone book a high priority meeting within a time-block allocated a less priority task. I'll get a notification of this re-scheduling. Here’s a more detailed article of their value proposition.

Reclaim is entirely free for now and will continue being so forever. However, they’ll add some premium packages (pro and team) starting March 28th 2022.

Using my invite link to register to reclaim will greatly help support this blog.

Asana: project management

I’ve been using Asana for a long time to manage my projects. Asana helps me organize and visualize any sort of project that I may be working on.

While I may not take many projects at a time, it always helps to have structure and I find their kanban boards super appealing and intuitive.

They have a basic plan which is free and suited for individuals getting started with project management. Check out their pricing page for the premium and business plan fees.

Coda

Last but not least, it’s important to note that these tools will not necessarily make your business successful as a solo entrepreneur. The most important thing I’ve found is to have a solid reputation, network, work ethic and quality work. These tools enhance your work and bring somewhat of a work-life balance. You can always do without them.

Know any other cool apps I don’t know about? Let me know in the comments and I’ll include them in this list.

Deploying Next.js apps to a VPS using Github actions and Docker

Lewis kori — Fri, 17 Dec 2021 09:18:54 +0000

Recently, I had to deploy a project to a DigitalOcean droplet. One of the features I really wanted for this particular project was a Continuous Delivery pipeline.

The continuous delivery website defines this as

the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.

The goal is to make deployments—whether of a large-scale distributed system, a complex production environment, an embedded system, or an app—predictable, routine affairs that can be performed on demand.

For my case I wanted the web app to auto-deploy to the VPS whenever I pushed changes to the main Github branch. This would consequently save a lot of development time in the process.

Alternative solutions

There are alternative and hustle-free solutions to this such as Vercel and DigitalOcean app platform. However one may take my route if:

You want to better understand Github actions
Learn more about docker
For Vercel's case, your client or organization may want to keep their apps in a central platform for easier management.

Prerequisites

Please note that some of the links below are affiliate links and at no additional cost to you. Know that I only recommend products, tools and learning services I've personally used and believe are genuinely helpful. Most of all, I would never advocate for buying something you can't afford or that you aren't ready to implement.

A Github account
A virtual private server. I used a DigitalOcean droplet running Ubuntu 20.04 LTS. Sign up with my referral link and get $100 in credit valid for 60 days.

Create next.js app

We'll use npx to create a standard next.js app

npx create-next-app meta-news && cd meta-news

Once we're inside the project directory, we'll install a few dependencies for demonstration purposes

yarn add @chakra-ui/react @emotion/react@^11 @emotion/styled@^11 framer-motion@^4 axios

We'll also declare environment variables inside the .env.local file. We can then reference these variables from our app like so process.env.NEXT_PUBLIC_VARIABLE_NAME

NEXT_PUBLIC_BACKEND_URL=http://localhost:8000/api
NEXT_PUBLIC_META_API_KEY=your_api_key

These variables are for demonstration purposes only. So we won't really be referencing them within our app. An example of a place you'd call them is when instantiating an axios instance or setting a google analytics id and you don't want to commit that to the version control system.

Let's do a quick test run. The app should be running on localhost:3000 if everything is setup properly.

yarn start

Dockerizing the app

Docker is an open-source tool that automates the deployment of an application inside a software container. which are like virtual machines, only more portable, more resource-friendly, and more dependent on the host operating system. for detailed information on the workings of docker, I'd recommend reading this article and for those not comfortable reading long posts, this tutorial series on youtube was especially useful in introducing me to the concepts of docker.

We'll add a Dockerfile to the project root by running
touch Dockerfile within the CLI.

# Install dependencies only when needed
FROM node:alpine AS deps
# Check https://github.com/nodejs/docker-node/tree/b4117f9333da4138b03a546ec926ef50a31506c3#nodealpine to understand why libc6-compat might be needed.
RUN apk update && apk add --no-cache libc6-compat && apk add git
WORKDIR /app
COPY package.json yarn.lock ./
RUN yarn install --immutable


# Rebuild the source code only when needed
FROM node:alpine AS builder
# add environment variables to client code
ARG NEXT_PUBLIC_BACKEND_URL
ARG NEXT_PUBLIC_META_API_KEY


ENV NEXT_PUBLIC_BACKEND_URL=$NEXT_PUBLIC_BACKEND_URL
ENV NEXT_PUBLIC_META_API_KEY=$NEXT_PUBLIC_META_API_KEY

WORKDIR /app
COPY . .
COPY --from=deps /app/node_modules ./node_modules
ARG NODE_ENV=production
RUN echo ${NODE_ENV}
RUN NODE_ENV=${NODE_ENV} yarn build

# Production image, copy all the files and run next
FROM node:alpine AS runner
WORKDIR /app
RUN addgroup -g 1001 -S nodejs
RUN adduser -S nextjs -u 1001

# You only need to copy next.config.js if you are NOT using the default configuration. 
# Copy all necessary files used by nex.config as well otherwise the build will fail

COPY --from=builder /app/next.config.js ./next.config.js
COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
COPY --from=builder /app/pages ./pages

USER nextjs

# Expose
EXPOSE 3000

# Next.js collects completely anonymous telemetry data about general usage.
# Learn more here: https://nextjs.org/telemetry
# Uncomment the following line in case you want to disable telemetry.
ENV NEXT_TELEMETRY_DISABLED 1
CMD ["yarn", "start"]

We're running a multi-stage build for this deployment.
Notice the ARG and ENV keywords? That's how we pass our environment variables to the client code since we won't have access to any .env files within the container. More on this later.

We'll then build and tag our image

docker build --build-arg NEXT_PUBLIC_BACKEND_URL=http://localhost:8000/api --build-arg NEXT_PUBLIC_META_API_KEY=your_api_key -t meta-news .

This may take a while depending on your internet connection and hardware specs.
Once everything checks out run the container

docker run -p 3000:3000 meta-news

Launch your browser and your app should be accessible at 'http://localhost:3000' 🎉

Set up Github actions

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.

For more about this wonderful platform, head over to their official tutorial page

We'll create our first workflow by running the following commands in the CLI. You can use the GUI if you aren't comfortable with the command line 🤗.

mkdir .github && mkdir ./github/workflow && touch ./github/workflows/deploy.yml && nano ./github/workflows/deploy.yml

Populate the deploy.yml file with the following values.

name: Build and Deploy

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
  push:
    branches: [main]
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning'

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest
    container: node:14

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      - name: Build and Publish to Github Packages Registry
        uses: elgohr/Publish-Docker-Github-Action@master
        env:
          NEXT_PUBLIC_BACKEND_URL: ${{ secrets.APP_NEXT_PUBLIC_BACKEND_URL }}
          NEXT_PUBLIC_META_API_KEY: ${{ secrets.APP_NEXT_PUBLIC_META_API_KEY }}
        with:
          name: my_github_username/my_repository_name/my_image_name
          registry: ghcr.io
          username: ${{ secrets.USERNAME }}
          password: ${{ secrets. GITHUB_TOKEN }}
          dockerfile: Dockerfile
          buildargs: NEXT_PUBLIC_BACKEND_URL,NEXT_PUBLIC_META_API_KEY
          tags: latest

      - name: Deploy package to digitalocean
        uses: appleboy/ssh-action@master
        env:
          GITHUB_USERNAME: ${{ secrets.USERNAME }}
          GITHUB_TOKEN: ${{ secrets. GITHUB_TOKEN }}
        with:
          host: ${{ secrets.DEPLOY_HOST }}
          port: ${{ secrets.DEPLOY_PORT }}
          username: ${{ secrets.DEPLOY_USER }}
          key: ${{ secrets.DEPLOY_KEY }}
          envs: GITHUB_USERNAME, GITHUB_TOKEN
          script: |
            docker login ghcr.io -u $GITHUB_USERNAME -p $GITHUB_TOKEN
            docker pull ghcr.io/my_github_username/my_repository_name/my_image_name:latest
            docker stop containername
            docker system prune -f
            docker run --name containername -dit -p 3000:3000 ghcr.io/my_github_username/my_repository_name/my_image_name:latest

You may have noticed our actions are very secretive 😂. Worry not, this is deliberately done to protect your sensitive information from prying eyes. They're encrypted environment variables that you(repo owner) creates for a repo that uses Github actions.

One thing to note is that the GITHUB_TOKEN secret is automatically created for us when running the action.

To create secrets go to your repository > settings > left-sidebar > secrets

For an in-depth walkthrough, see this guide.

The expected Github secrets are

APP_NEXT_PUBLIC_BACKEND_URL - live backend server url
APP_NEXT_PUBLIC_META_API_KEY - prod api key to thirdparty integration
DEPLOY_HOST - IP to Digital Ocean (DO) droplet
DEPLOY_KEY - SSH secret (pbcopy < ~/.ssh/id_rsa) and the public key should be added to `.ssh/authorized_keys` in server
DEPLOY_PORT - SSH port (22)
DEPLOY_USER  - User on droplet
USERNAME - Your Github username

Lift Off 🚀

Push to the main branch

git add -A
git commit -m "Initial commit"
git push origin main

If everything runs as expected, you should see a green checkmark in your repository with the build steps complete.

From there, you can setup a reverse proxy such as nginx within your server and point the host to "http://localhost:3000".

Yay!🥳 we have successfully created a continuous delivery pipeline and hopefully, now you'll concentrate on code instead of infrastructure.

Should you have any questions, please do not hesitate to reach out to me on Twitter.
Comment below if you have feedback or additional input.

Shameless plug

Do you need to do a lot of data mining?

Scraper API is a startup specializing in strategies that'll ease the worry of your IP address from being blocked while web scraping.They utilize IP rotation so you can avoid detection. Boasting over 20 million IP addresses and unlimited bandwidth.

In addition to this, they provide CAPTCHA handling for you as well as enabling a headless browser so that you'll appear to be a real user and not get detected as a web scraper. It has integration for popular platforms such as python ,node.js, bash, PHP and ruby. All you have to do is concatenate your target URL with their API endpoint on the HTTP get request then proceed as you normally would on any web scraper. Don't know how to webscrape?
Don't worry, I've covered that topic extensively on the webscraping series. All entirely free!

Using my scraperapi referrall link and the promo code lewis10, you'll get a 10% discount on your first purchase!! You can always start on their generous free plan and upgrade when the need arises.

How to programatically unzip files uploaded to google cloud storage buckets

Lewis kori — Thu, 29 Jul 2021 12:30:04 +0000

I've been using google cloud services over the last year and I thoroughly enjoy their range of services. In this walkthrough, I'll guide you through the process of unzipping files uploaded to Google cloud storage buckets. But first, let me give you some context.

The problem

Over the course of this week, I've had the challenge of ensuring that zip files uploaded from a web app interface are immediately unzipped once they're uploaded to a storage service. Zip files are a convenient way of uploading bulk data as they're minified, hence save a lot of bandwidth while they're being uploaded.

However, you may need to access individual files located in the zip files once uploaded to your asset holding service. In my case, I needed to access a plethora of pdf statements.

I have been using several services in the google cloud suite in conjunction with google cloud storage
These are:

Google cloud run - their managed serverless allowing developers to develop and deploy highly scalable containerized applications.
Google cloud secret manager - Stores API keys, passwords, certificates, and other sensitive data.
Google cloud databases mainly Postgres

Having come from using traditional Virtual machines (VMs), I had to change my mindset in regards to hosting each service in the same machine. Having offloaded the storage of objects to the GS bucket, I simply couldn't traverse the local file system and unzip the files directly. After a lot of pain and pulling hair 😂, I finally managed to accomplish this seemingly impossible task.

Let's get to it.

The solution

For this walkthrough, we'll write some python scripts that'll automate the unzipping process.

If you're not familiar with google cloud services, this tutorial will help you get started with the basics. In case you're feeling extra curious, here's a complete guide to deploy a django app to cloud run. This will equip you with the knowledge and hands-on experience of most of the services mentioned above.

Project set up

Since this is a python project, it's recommended to use virtual environments to manage and separate dependencies.

virtualenv unzipperEnv -p python3.9 // create virtualenv
source unzipperEnv/bin/activate // activate virtualenv

Once activated, we'll have to install a few libraries to interact with the google cloud suite.

google-cloud-storage
google-auth
django-storages - just in case you are using Django. We won't necessarily need this here but it's highly useful in a production app.

pip install google-auth google-cloud-storage

Let's jump right to it by creating a directory to house our project. I'll be using Unix commands but you can use the UI or PowerShell in case you're on windows.

mkdir unzipper && cd unzipper // create and enter a directory
touch storages.py // create a script to house our code
code . // open code editor

Great, so far, so good. We'll jump right to the crux of our walkthrough.

working with google storage buckets

Before getting started, we'll need to create a google cloud storage bucket. I won't cover that today as it has been widely documented in their official docs.
Once, you've created a bucket, you'll get a bucket id, we'll need that going forward.

In the process of creating the bucket, ensure you get a service account and download the JSON file provided by Google.
This will help us authenticated the requests while testing locally on our machines. I've saved mine as credentials.json

import io
from zipfile import ZipFile, is_zipfile

from google.cloud import storage
from google.oauth2 import service_account

# declare unzipping function

def zipextract(zipfilename_with_path):

    # auth config
    SERVICE_ACCOUNT_FILE = 'credentials.json'
    credentials = service_account.Credentials.from_service_account_file(
        SERVICE_ACCOUNT_FILE)

    bucketname = 'your-bucket-id'

    storage_client = storage.Client(credentials=credentials)
    bucket = storage_client.get_bucket(bucketname)

    destination_blob_pathname = zipfilename_with_path

    blob = bucket.blob(destination_blob_pathname)

    zipbytes = io.BytesIO(blob.download_as_string())

    if is_zipfile(zipbytes):
        with ZipFile(zipbytes, 'r') as myzip:
            for contentfilename in myzip.namelist():
                contentfile = myzip.read(contentfilename)

                # unzip pdf files only, leave out if you don't need this.
                if '.pdf' in contentfilename.casefold():

                    output_file = f'./{contentfilename.split("/")[-1]}'
                    outfile = open(output_file, 'wb')
                    outfile.write(contentfile)
                    outfile.close()

                    blob = bucket.blob(
                        f'{zipfilename_with_path.rstrip(".zip")}/{contentfilename}'
                    )
                    with open(output_file, "rb") as my_pdf:
                        blob.upload_from_file(my_pdf)

                    # make the file publicly accessible
                    blob.make_public()
    print('done running function')

if __name__ == '__main__':
    zipfilename_with_path = input('enter the zipfile path: ')
    zipextract(zipfilename_with_path)

Looking at the code above, what we're doing is declaring a function that takes in the zipfile location within our bucket. This can be documents/reports/2021/January.zip

In order to access our storage buckets in this script, we have to authenticate the request through the credentials.json (service account details). Under the hood, the google cloud libraries use the requests module.

Blobs are google cloud's concept of an object. This path to the object(zip) is what we provide to our function. From there, we download the zip file as a string and convert its representation to bytes through the io standard python library.

is_zipfile checks our byte representation of the zip file to ensure what we want to unzip is an actual zip file.

 with ZipFile(zipbytes, 'r') as myzip:
            for contentfilename in myzip.namelist():
                contentfile = myzip.read(contentfilename)

From the snippet above, we'll be reading in the zipbytes and loop through its content.

For my use case, I wanted to unzip pdf files, but you can be creative with this. I used the pattern in the name, checking if there are filenames with .pdf extension. It's probably not the best method as the pdf may not be accurate. This StackOverflow question offers some interesting solutions. In my case, however, I was content with the workaround.

if '.pdf' in contentfilename.casefold():

                    output_file = f'./{contentfilename.split("/")[-1]}'
                    outfile = open(output_file, 'wb')
                    outfile.write(contentfile)
                    outfile.close()

                    blob = bucket.blob(
                        f'{zipfilename_with_path.rstrip(".zip")}/{contentfilename}'
                    )
                    with open(output_file, "rb") as my_pdf:
                        blob.upload_from_file(my_pdf)

                    # make the file publicly accessible
                    blob.make_public()

We then extract the bytes and write them to a file within our project directory with the same name as what's available in the bucket. Immediately after, we take this file and upload it to the newly extracted zip folder. The rstrip() function ensures the extracted folder doesn't have .zip extension in its name.

Finally, we ensure the newly extracted files are publicly accessible via URL so that users can easily download them from an app or website interface.

conclusion and gotchas

The snippet above is very useful when testing on your own machine, however, if your app is running in any of google's serverless environments, namely, app engine and cloud run, it's recommended to write files to a directory named /tmp.
All files in this directory are stored in the instance's RAM, therefore writing to /tmp takes up system memory. In addition, files in the /tmp directory are only available to the app instance that created the files. When the instance is deleted, the temporary files are deleted. This will ensure the files we're writing and re-uploading are deleted as soon as possible since we no longer need them.

We'll modify our script slighty to accomodate this.

    # change path here 👇🏽
    output_file = f'/tmp/{contentfilename.split("/")[-1]}'
                    outfile = open(output_file, 'wb')
                    outfile.write(contentfile)
                    outfile.close()

additionally, we won't be needing the service account credentials in that environment.

"""
this line changes and there's no need for auth module imports
storage_client = storage.Client(credentials=credentials)
"""

# no credential requirements
storage_client = storage.Client()

Thanks for your time, if you want more of this, subscribe to my newsletter to get notified whenever I make new posts.

That's it from me.

If you have any questions or issues, leave a comment below or contact me via twitter and I'll get to you as soon as I can.