Forem: Frank Oge

The 2026 Playbook: How to Optimize Your LinkedIn to Attract US Tech Recruiters

Frank Oge — Mon, 02 Mar 2026 21:14:20 +0000

You have a perfect GitHub graph. You have mastered React, Node.js, and Python. You build side projects every weekend. Yet, your LinkedIn inbox is completely empty, while other developers are landing remote US jobs paying $80,000+ a year.
Why? Because US tech recruiters do not look at your GitHub first. They look at your LinkedIn.
If your profile looks like a generic list of programming languages, you will be ignored. Recruiters search LinkedIn using specific keywords, filters, and risk-assessment metrics. If you want to attract high-paying foreign roles, you need to treat your profile like an SEO-optimized landing page.
Here is exactly how to optimize your LinkedIn profile to make US recruiters come to you.
1. The Headline: Your Value Proposition
Your headline is the most important real estate on your profile. It is the only thing a recruiter sees in the search results alongside your photo.
Stop using headlines like:
"Software Developer" (Too broad)
"Actively looking for roles" (Looks desperate, wastes space)
"HTML | CSS | JS | React" (Looks like a junior bootcamp grad)
The Fix: Use the "Title + Niche + Value" formula.
"Senior Frontend Engineer (React/Next.js) | Building High-Performance SaaS Interfaces | Remote (EST Overlap)"
2. Address the "Remote Risk" Instantly
When a US recruiter looks at a profile based in Nigeria or elsewhere in Africa, their immediate internal questions are: "Will timezones be an issue? Can they communicate well asynchronously?"
You must answer these questions before they even ask.
Location Strategy: If you are open to global remote work, state your timezone overlaps clearly in your "About" section.
Example: "Fully equipped for remote work with high-speed redundancy. Comfortable working with async communication and overlapping with EST/PST business hours."
3. The Experience Section: Metrics Over Duties
Nobody cares that your duty was to "write code for the backend." That is expected. Recruiters (and Engineering Managers) want to know what happened because you wrote that code.
Transform your bullet points from tasks to business outcomes:
The Amateur Developer (Tasks) The Senior Engineer (Impact)
Built a new payment gateway. Integrated Stripe API, reducing checkout friction and increasing conversion by 15%.
Fixed database bugs. Optimized PostgreSQL queries, reducing API response time from 2s to 300ms.
Managed the frontend team. Led

The "About" Section: Speak to the Business Do not start your summary with "Ever since I was a child, I loved computers..." Recruiters spend an average of 6 seconds scanning your profile. Give them the facts. Format your "About" section like this: Who you are: "I am a Backend Engineer with 5 years of experience scaling Node.js/Python applications." What you specialize in: "I specialize in system architecture, API design, and cloud deployments (AWS/Vercel)." Your current goal: "Currently looking for a remote role with a forward-thinking product team." Conclusion Recruiters are actively searching for you. But if you hide behind poor formatting, vague headlines, and a lack of business context, they will scroll right past you. Optimize your profile for search, prove your communication skills, and highlight your business impact. The DMs will follow. Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com

The Developer’s ROI: Why Your Chair and Keyboard Matter More Than Your Tech Stack

Frank Oge — Sun, 01 Mar 2026 22:51:50 +0000

Developers will happily spend $3,000 on a maxed-out MacBook Pro with an M-series chip. They will spend weeks debating the performance differences between Rust and Go.
But then, they will sit on a $40 plastic dining chair and type on a flat, mushy laptop keyboard for 10 hours a day.
This is the ultimate paradox of the modern software engineer. We obsess over the performance of our machines, while completely ignoring the performance bottlenecks of our own bodies.
If you want a long, highly profitable career in tech, the best investment you can make isn't a new course or a faster CPU. It is an ergonomic chair and a high-quality mechanical keyboard. Change my mind.
Here is the business case for investing in your physical hardware.
1. The Chair: Spinal Health is Career Longevity
Your brain writes the code, but your spine supports the operation.
When you sit in a cheap chair, your posture collapses. Your shoulders roll forward, your lower back loses its natural curve, and your neck strains to look at the monitor.
The Cost: Chronic back pain is the silent killer of developer productivity. You cannot focus on complex system design when your L4 vertebra is screaming at you.
The ROI: A high-end ergonomic chair (like a Herman Miller, Steelcase, or a premium local alternative) is not a luxury purchase; it is a medical investment. It forces your body into an active, supported posture. If a $1,000 chair prevents a single week of lost work due to back spasms, it has already paid for itself.
2. The Keyboard: Tactile Feedback and RSI Prevention
The keyboard is your primary interface with the digital world. It is the steering wheel of your career.
Laptop keyboards and cheap membrane boards require you to "bottom out" (press the key all the way down until it hits the hard plastic) to register a keystroke. Doing this 10,000 times a day sends micro-shocks up your fingers, leading directly to Repetitive Strain Injury (RSI) and Carpal Tunnel Syndrome.
The Mechanical Advantage: Mechanical keyboards use individual physical switches. You can feel the exact moment the key actuates before it hits the bottom. This tactile feedback allows you to type lighter, faster, and with significantly less strain on your tendons.
Customization: Whether you prefer the heavy click of a Blue switch or the smooth glide of a linear Red switch, you can tailor the tool to your exact physical mechanics.
The Professional Setup Breakdown

Gear The Amateur Setup The Professional Setup
Seating Dining chair / Cheap gaming chair Ergonomic task chair with lumbar support
Input Flat laptop keyboard Mechanical (or ergonomic split) keyboard
Screen Looking down at a 13" laptop Eye-level external monitor
Result Back pain, wrist fatigue, brain fog Deep

Conclusion
You are a professional athlete of the knowledge economy. A Formula 1 driver wouldn't race in a cheap seat with a plastic steering wheel.
Stop treating your body like a secondary component. Buy the chair. Buy the keyboard. Your 40-year-old self will thank you.

Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com

The Hidden Cost of Cheap: Why I Stopped Arguing with Low-Ball Clients

Frank Oge — Sat, 28 Feb 2026 22:05:43 +0000

It’s the most common objection in the freelance world. You’ve spent an hour on a discovery call, mapped out a technical architecture, and presented a fair quote. Then comes the line:
"I can find someone on [Freelance Site] to do this for 20% of your price."
In the past, I would have panicked. I would have started justifying my hourly rate or, worse, offered a discount.
Today? My answer is simple: "Okay. I understand. Good luck with the project."
Here is why "Okay" is the most powerful word in a senior developer's vocabulary, and why competing on price is a race to the bottom that you don't want to win.
1. Price is What You Pay, Cost is What You Endure
In software, a low initial price is almost always a down payment on future technical debt.
When a client hires the "cheapest" option, they aren't just saving money; they are often buying:
Brittle Code: Lack of tests and poor architecture that breaks under load.
Communication Gaps: Endless back-and-forth because the developer doesn't understand the business requirements.
The "Do-Over" Tax: Eventually, they will have to hire a professional (like you) to delete the cheap code and rebuild it from scratch.
2. You are an Asset, Not an Expense
Low-ballers view developers as a "cost center"—like office supplies or electricity.
High-value clients view developers as "revenue generators."
If your software is going to automate a $100k/year process, it doesn't matter if you charge $5k or $10k. The value is in the result. If a client can't see that, they aren't looking for a partner; they are looking for a pair of typing hands. You don't want that contract.
3. The Comparison Table
When a client tries to low-ball you, keep this internal table in mind. It will give you the confidence to say "No."

The Cheap Developer The Professional Engineer
Focuses on "Features" Focuses on "Business Outcomes"
Writes code that "Works for now" Writes code that is "Maintainable and Scalable"
Needs a micro-managed checklist Needs a high-level goal
Is a liability (Risk) Is an investment (Growth)

Conclusion
When you say "Okay" to a low-baller, you aren't being arrogant. You are protecting your schedule for the clients who actually value high-performance software.
The best clients don't want the cheapest developer; they want the developer who makes the problem go away the first time.

Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com

The 2026 Guide: 3 Ways to Accept USD in Nigeria Without Getting Blocked

Frank Oge — Fri, 27 Feb 2026 22:43:41 +0000

If you work in tech in Nigeria, you already know the heartbreak. You land a $5,000 contract with a US client, deliver the code, and then the nightmare begins: How do I actually get paid?
PayPal doesn't let you receive. Payoneer randomly blocks accounts. Direct bank wires take weeks and often convert at terrible, centralized FX rates.
As a Nigerian developer or SaaS founder, your payment infrastructure is just as important as your tech stack. If you can't collect the money, you don't have a business.
Here are the 3 most reliable ways to accept USD in Nigeria today, without the fear of waking up to a suspended account.
1. The Freelancer's Choice: Virtual USD Accounts (Grey / Geegpay)
If you are a freelancer or contractor, your foreign clients want to pay you the way they pay everyone else: via local bank transfer (ACH in the US, SEPA in Europe).
The Solution: Platforms like Grey.co or Geegpay provide you with a legitimate, virtual US routing and account number.
How it works: You put these account details on your invoice. Your client sends an ACH transfer that clears in 1-2 business days. The platform then allows you to swap that USD to Naira at the parallel market rate and withdraw directly to your local Nigerian bank account in minutes.
Why it wins: Zero friction for the client. They don't need to download new apps; they just do a standard bank transfer.
2. The Unblockable Route: Stablecoins (USDC / USDT)
For clients who are forward-thinking, Web3 infrastructure has solved the cross-border payment problem permanently.
The Solution: Invoicing in USDC (USD Coin) or USDT (Tether) over low-cost networks like Solana, Base, or Polygon.
How it works: You generate a receiving address from a non-custodial wallet (like Phantom or MetaMask). The client sends the stablecoin.
The Math: A $3,000 payment settles in 400 milliseconds. The transaction fee is roughly $0.01. No intermediary bank can freeze the transaction, and no weekend delays apply.
To Naira: You can easily off-ramp your USDC to Naira using trusted P2P exchanges or local platforms like Yellow Card.
3. The SaaS Founder's Route: The US LLC Setup (Stripe)
If you are building a SaaS product, you cannot ask 1,000 users to manually send you crypto or wire transfers. You need automated, recurring card payments. You need Stripe or Lemon Squeezy.
The Problem: Stripe does not support Nigerian-registered businesses directly. If you try to fake your location with a VPN, you will be permanently banned.
The Solution: Form a US LLC using a service like Stripe Atlas or Firstbase.io.
How it works: For about $500, these services legally register your company in Delaware or Wyoming, get you a US Employer Identification Number (EIN), and open a US business bank account (like Mercury). With a legitimate EIN and US bank account, you can open a fully compliant Stripe account from Nigeria.

Method Best For Client Friction Risk of Block
Virtual Accounts (Geegpay/Grey) Freelancers, Agencies Low Low
Stablecoins (USDC/USDT) Forward-thinking clients Medium Zero
US LLC + Stripe SaaS Founders Zero Low (If fully compliant)

Conclusion
Stop losing international clients because of payment friction. The infrastructure exists. Set up your virtual accounts, educate your clients on stablecoins, or incorporate globally. Your code is world-class; your payment stack should be too.

Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com

The Hourly Trap: Why Freelance Developers Must Switch to Value-Based Pricing in 2026

Frank Oge — Thu, 26 Feb 2026 22:22:10 +0000

There is a fatal flaw in how 90% of freelance software developers run their businesses: Hourly billing inherently punishes efficiency.
Think about it. When you were a junior developer, it might have taken you 20 hours to set up a secure authentication flow and a Stripe payment integration. At $50 an hour, you made $1,000.
Today, you are a senior developer. You have boilerplate code, immense experience, and AI tools like Cursor or Claude 3.5 Sonnet. That exact same Stripe integration now takes you 2 hours. If you still charge $50 an hour, you just made $100.
You got better, you got faster, and your reward was a 90% pay cut.
If you want to scale your income in 2026, you have to stop selling your time. You must transition to Value-Based Pricing. Here is exactly how to do it.
1. What is Value-Based Pricing?
Value-based pricing means setting your fee based on the financial impact your work has on the client's business, rather than the time it takes you to type the code.
Clients do not care about your code. They care about what your code does for their business.
Does it increase revenue?
Does it reduce churn?
Does it save their team 40 hours of manual data entry a week?
If your custom software automates a process that saves a company $100,000 a year, charging them a flat fee of $15,000 is an absolute bargain—even if it only takes you three days to build.
2. The "Discovery Call" Pivot
To charge for value, you have to uncover the value. You can no longer start calls by asking, "What tech stack do you want?" You must ask the Money Questions:
"What is the main business problem this software is trying to solve?"
"How much is this problem currently costing you in lost revenue or wasted time?"
"If we build this perfectly, how much new revenue do you expect it to generate in the next 12 months?"
3. The Proposal Framework
Once the client admits that the new feature will generate roughly $50,000 in new sales this year, you anchor your price against that number.
Do not send a proposal that says: "40 hours of React Development @ $100/hr = $4,000." This invites the client to argue about how long things take.
Instead, frame it around the ROI (Return on Investment):

Project Phase Business Outcome Investment
Phase 1: Payment Architecture Reduces checkout abandonment by estimated 15%.

Phase 2: Automated Invoicing Saves accounting team 20 hours/week.

Total Investment Positioned to unlock $50k+ in annual value. $8,500 Flat Fee

Conclusion
When you price by the hour, you and the client have opposing goals: You want to work more hours to get paid more, and the client wants you to work fewer hours to keep costs down.
When you price by value, your goals align perfectly. They want a high-impact solution quickly, and you want to deliver a high-impact solution quickly.
Stop letting your typing speed dictate your net worth. Become a partner, not a commodity.
Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com

How Uber Handles Millions of Rides: A System Design Masterclass

Frank Oge — Thu, 26 Feb 2026 03:08:58 +0000

You open your phone, press "Confirm Ride," and within 3 seconds, a driver is assigned to you.
As a user, it feels like magic. As a software engineer, you know it is a chaotic symphony of microservices, geospatial indexing, and real-time data streams.
If you tried to build Uber using a standard monolithic architecture and a SQL database, your server would crash the moment you hit 1,000 concurrent users. You cannot simply run a query like SELECT * FROM drivers WHERE location = 'Lagos' AND distance < 5km. The database would lock up instantly.
So, how does Uber actually do it? Let's break down the architecture.
1. The Geospatial Problem: H3 (The Hexagon Grid)
Uber’s biggest challenge is calculating distance instantly. To solve this, they created and open-sourced H3, a Hexagonal Hierarchical Spatial Index.
Instead of calculating the exact latitude and longitude of every user against every driver, Uber divides the entire Earth into a grid of hexagons.
The Magic: When you open the app, Uber instantly knows which "hexagon" you are standing in.
The Match: It then only searches for drivers who are pinging their location inside your specific hexagon (and the immediate neighboring hexagons). This turns a massive, computationally heavy math problem into a simple, lightning-fast dictionary lookup.
2. The Data Firehose: Kafka
Drivers send their GPS coordinates to Uber's servers every 4 seconds. Imagine 1 million drivers online. That is 250,000 write requests per second.
No standard database can handle that directly.
The Solution: Uber uses Apache Kafka. Kafka acts as a massive shock absorber. It ingests the millions of GPS pings, queues them up, and streams them to the mapping services and databases without dropping a single packet of data.
3. The Matchmaker: WebSockets and DISCO
When you request a ride, your phone establishes a persistent WebSocket connection with Uber’s Dispatch System (internally called DISCO).
Why WebSockets? HTTP requests are too slow for real-time tracking because they require opening and closing a connection every time. WebSockets keep the tunnel open, allowing the server to push the driver's live location to your screen continuously.
The Logic: DISCO looks at the active drivers in your H3 hexagon, filters out those already on a trip, and sends a push notification to the closest driver.
4. The Memory: Cassandra
Where do you store billions of completed trips, ratings, and driver logs?
Uber uses Apache Cassandra, a highly scalable NoSQL database.
Cassandra is designed for high-write environments. It allows Uber to store petabytes of trip data across multiple data centers globally, ensuring that even if an entire server farm in Europe goes offline, the app stays up.
Summary Architecture Table
Component Technology Purpose in the System
Location Tracking H3 (Hexagons) Lightning-fast geospatial lookups.
Data Ingestion Apache Kafka Handling 250k+ GPS pings per second.
Real-Time Comms WebSockets Live map updates without refreshing.
Database Storage Cassandra Highly available, distributed data storage.

Conclusion
Uber is not just an app; it is a massive distributed system handling extreme scale. The next time you order a ride and watch that little car move on your screen, you’ll know exactly the data pipeline powering it.
Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com

"Web3 is Dead." No, You Just Don't Understand Utility.

Frank Oge — Tue, 24 Feb 2026 22:22:35 +0000

If you judge the internet solely by the dot-com crash of the early 2000s, you would have called it a failure. If you judge Web3 solely by the cartoon monkey JPEGs and algorithmic stablecoin crashes of the early 2020s, you are making the exact same mistake.
The media loves to declare Web3 "dead." But as a software engineer building high-performance systems in 2026, I can tell you that Web3 isn't dead. It just graduated.
The casino is finally closed. The infrastructure phase has begun. Here is why Web3 is quietly powering the next generation of global software, and why you are missing the bigger picture if you ignore it.
1. The Stablecoin Revolution
For someone living in New York or London, a bank works just fine. But if you live in Lagos, Buenos Aires, or Istanbul, your local currency is actively losing purchasing power.
Web3 introduced the most important financial primitive of our decade: The Stablecoin (USDC, USDT).
The Problem: Getting paid as an African remote developer by a US company used to take 5 days and cost 8% in SWIFT fees and terrible FX rates.
The Utility: Today, a smart contract on Solana or Base settles a $5,000 USDC payment in 400 milliseconds for a fraction of a cent.
It is not an investment. It is a utility. It is a superior database for money.
2. TradFi vs. Web3 Settlement
Let's look at the actual technical difference between Traditional Finance (TradFi) and Web3 architecture when sending data (value) across borders.

Feature Traditional Finance (SWIFT/Banks) Web3 Infrastructure (L2s/Solana)
Uptime Monday - Friday, 9 AM to 5 PM. 24/7/365. Never sleeps.
Settlement Time 2 to 5 business days. Under 2 seconds.
Intermediaries 3-4 corresponding banks. Zero. Peer-to-peer.
Transparency Black box. You wait and hope. Public ledger. Fully verifiable.

When you view blockchain purely as a distributed ledger designed to remove middlemen, the "Web3 is dead" narrative instantly falls apart.
3. Real World Assets (RWAs)
We are no longer tokenizing digital art; we are tokenizing reality.
In 2026, the biggest financial institutions are moving into RWAs. This means taking physical assets—like real estate, treasury bills, or agricultural supply chains—and representing them as tokens on a blockchain.
Fractional Ownership: A developer in Nairobi can now buy $50 worth of tokenized US Treasury bills to hedge against inflation, yielding 5% directly into their wallet.
Liquid Markets: Assets that traditionally took months to sell (like commercial real estate) can now be traded instantly on decentralized exchanges.
Conclusion
Web3 did not die; it just became boring. And in software engineering, "boring" is exactly what you want your infrastructure to be.
Stop looking at the price of volatile tokens. Start looking at the GitHub commits, the active wallet addresses using stablecoins, and the APIs settling cross-border payments. The hype is gone, but the utility is here to stay.
Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com

Beyond ChatGPT: The 5 AI Tools I Actually Use to Code 10x Faster

Frank Oge — Mon, 23 Feb 2026 22:05:54 +0000

Let me be incredibly clear: If your AI coding workflow consists of copying code from your editor, pasting it into a ChatGPT browser tab, and copying the result back... you are doing it wrong.
That context-switching destroys your flow state. In 2026, AI is no longer just a chatbot; it is deeply integrated into the developer ecosystem. It doesn't replace your logic, but it dramatically accelerates your execution.
Here are the 5 AI tools I actually use every single day to write, debug, and ship high-performance software.
1. Cursor: The AI-Native IDE
I abandoned standard VS Code a long time ago.
Cursor is a fork of VS Code, meaning all your extensions and themes still work, but it has AI built into its core.
The Magic: It understands your entire codebase. You can press Cmd+K and type: "Update the authentication middleware to use the new Redis schema we defined in db.ts," and it edits the code right in your file.
Why it wins: Context. It reads your local files, so it doesn't hallucinate variables that don't exist.
2. Claude 3.5 Sonnet: The Architect
When I need to design a complex system architecture or refactor a massive monolithic function, I don't use ChatGPT. I use Anthropic's Claude 3.5 Sonnet.
The Magic: Claude has a massive context window and is objectively better at handling large blocks of code without getting "lazy" or skipping lines.
Why it wins: If I dump 3,000 lines of spaghetti code into Claude and ask it to break it down into modular SOLID components, it actually does the work.
3. v0 by Vercel: The Frontend Engineer
Building UI components from scratch is tedious. Padding, margins, flexbox alignment—it eats up hours.
The Magic: v0 generates React (Next.js) components styled with Tailwind CSS purely from text prompts.
Why it wins: I type "A modern pricing table with a toggle for monthly/yearly billing, highlighting the pro tier in purple." In 15 seconds, I have a fully accessible, copy-pasteable Shadcn UI component.
4. Phind: The Developer Search Engine
Standard search engines are cluttered with SEO spam and outdated Stack Overflow answers from 2014.
The Magic: Phind is an AI search engine built explicitly for developers. It browses the live internet to read the latest documentation for frameworks like Next.js or Rust.
Why it wins: When a library updates its API and the AI models haven't been trained on it yet, Phind reads the live docs and gives you the correct, up-to-date syntax.
5. Mintlify: The Documenter
Every developer loves writing code. Every developer hates writing documentation.
The Magic: Mintlify Writer is an extension that reads your complex functions and automatically generates perfect, readable documentation comments (JSDoc, Python Docstrings, etc.).
Why it wins: You highlight a block of code, click a button, and it explains exactly what the parameters, return types, and edge cases are. Your codebase stays maintainable with zero extra effort.
Conclusion
AI will not replace software engineers. But a software engineer using AI will absolutely replace an engineer who refuses to adapt.
Stop treating AI like a search engine and start treating it like a junior developer who sits inside your terminal.
Would you like me to write a deep-dive tutorial on how to configure Cursor for a full-stack Next.js/Node environment? Let me know in the comments.
Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com

The "SaaS MVP" Tech Stack: How to Build and Launch in a Weekend

Frank Oge — Sun, 22 Feb 2026 20:45:27 +0000

The #1 reason most SaaS ideas die is not because they are bad ideas. It is because the developer spent three months building a custom authentication system, setting up a Kubernetes cluster, and configuring Webpack—all before writing a single line of business logic.
If you are building a Minimum Viable Product (MVP), your only goal is to answer one question: Will people pay for this?
To answer that question, you need speed. You need a tech stack that handles the boring stuff (auth, databases, UI components, payments) so you can focus strictly on the feature your users actually care about.
Here is the proven SaaS MVP Tech Stack that dominated 2025 and remains the absolute standard today.
1. The Core Framework: Next.js + TypeScript
You do not have time to build a separate React frontend and a Node.js Express backend. You need everything in one repository.
Next.js: Gives you a world-class React environment with file-based routing and Server-Side Rendering (SSR) out of the box. More importantly, Next.js API routes let you write your backend endpoints in the exact same codebase.
TypeScript: Skipping TypeScript to "save time" is a trap. You will spend 10x more time debugging type errors in production. Use it from Day 1.
2. The Database & Auth: Supabase
Do not write custom authentication. Do not manage a database server.
Why Supabase? It is an open-source Firebase alternative powered by a real PostgreSQL database.
The Magic: It gives you an instant REST/GraphQL API on top of your database, and it handles user authentication (Email/Password, Google, GitHub) out of the box. You just define your tables and start reading/writing data from your frontend.
3. The UI Layer: Tailwind CSS + Shadcn UI
Your MVP needs to look trustworthy, but you cannot afford to spend 40 hours tweaking CSS classes.
Tailwind CSS: Utility-first CSS. You style elements directly in your JSX. It enforces a consistent design system instantly.
Shadcn UI: This is the secret weapon. It is a collection of beautifully designed, accessible components (Buttons, Modals, Dropdowns) that you can copy and paste directly into your project. It looks like a premium enterprise app out of the box.
4. Payments: Stripe Checkout
If you want to validate a SaaS, you need to collect money.
Stripe: Still the undisputed king. Do not build custom billing pages. Use Stripe Checkout to redirect users to a secure Stripe-hosted payment page, and use Stripe Webhooks to update their subscription status in your Supabase database.
5. Hosting: Vercel
Deployment should not be a task; it should be an afterthought.
Vercel: Because you are using Next.js, Vercel is the natural choice. You connect your GitHub repository, push your code to the main branch, and Vercel automatically builds and deploys your application to a global edge network.
Summary Table
Layer Technology Why it wins for MVPs
Framework Next.js (TypeScript) Frontend and Backend in one repo.
UI/UX Tailwind + Shadcn Enterprise-grade components, zero CSS files.
Backend/DB Supabase Instant PostgreSQL API + built-in Auth.
Payments Stripe Trustworthy, easy webhook integration.
Hosting Vercel Zero-config, git-push-to-deploy.

Conclusion
Stop over-engineering. An MVP is an experiment, not an enterprise monolith. Use this stack, build the core feature this weekend, and launch it on Monday.
Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com

The Polyglot Trap: Why Mastering Just JavaScript and Python is Your Ultimate Superpower

Frank Oge — Sat, 21 Feb 2026 22:21:28 +0000

Every day, my feed is filled with developers asking the same question:
"Should I learn Rust? Is Go going to replace Node? Do I need to learn Swift for mobile?"
We have become obsessed with collecting syntax like Pokémon cards. But in 2026, the harsh truth is that nobody cares how many "Hello World" scripts you can write in different languages. The market pays for problem-solving, system architecture, and shipping speed.
If you want to build high-performance software, launch profitable SaaS products, and make yourself indispensable, stop language-hopping. Master JavaScript. Master Python. That is it.
Here is why this two-language stack covers 99% of the modern software industry.
1. JavaScript: The Language of Delivery
JavaScript (and by extension, TypeScript) has a monopoly on the user interface. It is the only language that runs natively in the browser, making it non-negotiable.
But it didn't stop there:
The Frontend: React, Vue, Next.js. You can build world-class web applications.
The Backend: Node.js allows you to write highly concurrent, non-blocking APIs without switching mental contexts.
Mobile & Desktop: React Native lets you deploy to iOS and Android. Electron/Tauri lets you build desktop apps.
If it has a screen, JavaScript can paint on it.
2. Python: The Language of Intelligence
If JavaScript is how you interact with the user, Python is how you think.
We are living in the AI and Data era. Python won this war a decade ago and its dominance is only growing.
Artificial Intelligence: PyTorch, TensorFlow, and LangChain are built for Python. If you want to integrate LLMs into your app, you need Python.
Data Processing: Pandas and NumPy handle massive datasets that would make JavaScript choke.
Automation: Scripting complex cron jobs, scraping the web, and gluing APIs together is effortlessly done in Python.
3. The Ultimate Architecture: The JS/Python Bridge
When you stop trying to learn C++ and Ruby, and focus solely on these two, you unlock the perfect modern architecture:
The Brain (Python): A FastAPI microservice that handles heavy data crunching, background tasks, and AI model inference.
The Face (JavaScript/TypeScript): A Next.js frontend backed by a Node.js API gateway that handles routing, authentication, and real-time user interactions via WebSockets.
Conclusion
A developer who has surface-level knowledge of 8 languages is a Junior. A developer who deeply understands the event loop in JavaScript and memory management in Python is a Senior.
Stop reading "Top 10 Languages to Learn in 2026" articles. Pick the browser's native tongue and the data scientist's weapon of choice. Then, get back to building.
Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com

Stop Accepting the "Africa Discount": How to Negotiate Remote Tech Salaries in 2026

Frank Oge — Fri, 20 Feb 2026 21:10:58 +0000

You passed the LeetCode tests. You crushed the system design interview. You met the founders, and they loved you. Then the offer letter arrives: $1,500 a month.
If you live in Lagos, Nairobi, or Accra, $1,500 might sound like a lot of money in local currency. But if the developer doing the exact same job in London is making $8,000 a month, you are not getting a good deal. You are being exploited via the "Africa Discount."
In 2026, remote work is global, but compensation is still heavily biased. Here is the practical framework to negotiate your salary as an African developer without losing the offer.
1. Defeating the "Cost of Living" Trap
When you ask for more money, HR will often say: "Our compensation is adjusted for your local cost of living."
This is a trap. Do not argue about your rent or the price of groceries.
Your response must pivot the conversation from Cost to Value.
The Reframe:
"I understand the company uses a geo-adjusted model. However, the code I am writing, the bugs I am fixing, and the features I am shipping bring the same exact value to the company's bottom line as they would if I lived in New York. I am looking for a rate that reflects the global market value of this output."
2. Research the "Band," Not the Minimum
Before you name a price, you need data.
Do not look at local Nigerian or Kenyan tech salaries. Look at the company's home market.
Use levels.fyi or remote-specific job boards to find the salary band for your role in their headquarters.
If their US band is $100k - $130k, do not ask for $30k just because it's good in Naira or Cedis.
Aim for the lower-to-middle end of their global band (e.g., $70k - $80k). It is still a massive discount for them, but a life-changing rate for you.
3. The "Flinch" and The Silence
When they state their initial lowball offer on a call, do not say "Okay, thank you."
Do not immediately accept.
Say: "I appreciate the offer. However, based on the responsibilities of this role and the technical depth required, that number is lower than I expected."
Then, stop talking. Silence makes people uncomfortable. Often, recruiters will immediately reveal that they have wiggle room just to fill the silence.
4. The Email Script
If you receive the offer via email, here is a template you can steal:
"Hi [Name],
Thank you for the offer. I am incredibly excited about the opportunity to join the team and help scale the backend infrastructure.
Regarding the compensation, I was expecting a base salary closer to the $X - $Y range. This is based on my 5 years of experience with Node.js/AWS, and the direct impact I expect to have on the Q3 deliverables we discussed.
Is there flexibility to bring the base salary closer to this range?
Looking forward to your thoughts."
Conclusion
Companies do not pull offers just because you negotiate professionally. Hiring is expensive. If they have chosen you, they want you.
Never let your IP address dictate your net worth. You are a global engineer. Get paid like one.
Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com

The Best Code is No Code: Why Your Codebase is a Liability, Not an Asset

Frank Oge — Thu, 19 Feb 2026 22:23:12 +0000

When you first learn to program, you feel like a wizard. You write a script, and the computer does what you say. You measure your productivity by the number of lines you commit.
"I wrote 500 lines of code today!" is the battle cry of the Junior Developer.
But as you transition into a Senior role, a dark realization sets in: Every line of code you write is a liability. It is something that has to be read, tested, debugged, and eventually updated when dependencies break.
Do I agree that "Less code = fewer bugs"? Absolutely. But there is a dangerous trap hidden in that statement. Here is how to think about code as a liability without destroying your codebase's readability.
1. The Maintenance Tax
Code is not a static asset like a house. It is a living organism that constantly decays.
Security: More code means a larger surface area for vulnerabilities.
Cognitive Load: When a new developer joins your team, they have to fit your logic into their brain. A 10,000-line microservice is infinitely harder to grasp than a 1,000-line one.
The Fix: Before you write a custom utility function, ask yourself: Does the standard library already do this? Can we solve this at the database level instead?
2. The "Less Code" Trap: Code Golfing
This is where the "less code" mantra goes wrong.
Some developers take it literally and try to compress complex logic into a single, unreadable line just to save vertical space. We call this "Code Golfing."

// A "Clever" One-Liner (High Liability)
const getActive = (u) => u.filter(x => x.s === 1 && x.a > 18).map(x => x.n);

// Boring, Readable Code (Low Liability)
const getActiveAdultUserNames = (users) => {
const activeAdults = users.filter(user => user.status === 1 && user.age > 18);
return activeAdults.map(user => user.name);
};

The first example is less code, but it is a higher liability because the next developer to read it will spend 10 minutes trying to decipher what x.s means.
Less code should mean less complexity, not just fewer keystrokes.
3. The Joy of Deleting Code
The best pull requests are the ones with negative lines of code.
When you refactor a messy module, delete a deprecated feature, or replace 500 lines of custom logic with a well-tested, open-source library, you are actively removing liability from your organization.
Conclusion
Your job as a software engineer is not to write code. Your job is to solve business problems. If you can solve a problem by deleting code, changing a process, or using an existing tool, you have done your job perfectly.
What is the biggest block of code you’ve ever deleted, and how did it feel? Let me know in the comments below!
Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com