DEV Community: Rash Edmund

Intergrating Payments to your SaaS from Cameroon shouldn’t be this much of a Hassle

Rash Edmund — Sat, 03 Oct 2026 23:00:26 +0000

In my last post about renaming Trivue to Tagviu, I mentioned having a rough time integrating international payments. This was mainly due to my region / geolocation.

I tried several popular payment providers and Merchant of Records: Polar, Stripe, Dodo Payments, Lemon Squeezy, Paystack, Flutterwave, and a few others.

The problem was:
A good number of them do not support businesses in many African countries.

Some of the payment gateways that do support a handful of African countries, like Paystack and Flutterwave, also currently do not support Cameroon

So I started looking locally.

I looked for tools built by Cameroonians, or at least providers that allowed operating in the CEMAC region. Anything that could let me accept international card payments for a product built in Cameroon.

I came across a few that seemed like a solution;

But most were built primarily around local payments like MTN MoMo and Orange Money.
I even found several that advertised card payments, only for me to sign up and discover that card payments weren't actually available.

Honestly, the quality of some of these platforms was disappointing.
Poor UI, Poor typography, Broken form validations, Weird things happening in the network tab etc...

Man I'd leave some of these sites thinking: "I know we can do better"

And that got me wondering:
Why aren't we more represented when it comes to global payment infrastructure?

Out of pure fraustration I kept asking; Is it the economy? Regulations? The developers? The market? something far deeper ? Is it me? Is it you?

At one point I even thought about what it would take to build my own payment platform for Cameroonians, and then African businesses, for accepting international payments. What it'll take to intergrate with banks like UBA, and EcoBank...

I could, but tbh:
There is bound to be a LOT of legal & financial hurdles (which I probably do not have the resources for), and potentially very very slow adoption, and also;
Do I wish things were in place already ? Absolutely!

But is that a rabbit hole i'm willing to go into rn ? Absolutely f*ing not.

So, I'm still looking.

I haven't integrated payments into Tagviu yet, but I have a potential way forward.

One way or another, Tagviu and all my SaaS Ideas are getting payments

Visit tagviu.com, to score your site's metadata

Trivue is Tagviu now. The name was the easy part.

Rash Edmund — Sat, 03 Oct 2026 21:50:04 +0000

Ok so...

Trivue is now Tagviu
Tagviu now has a dedicated docs site
I migrated the CLI, MCP server, database, API, and improved the overall dev-mode setup
I have an automated Tagviu X account that will try to convince you to use Tagviu...
And lastly, I'm dealing with the pain of integrating payments as a developer from Cameroon

I knew from the very beginning (while coming up with a name) that "Trivue" was already being used in a few places, but I went with it regardless.

Last weekend, while coming back from the 🏀 court, I realized:
"Tagviu" makes more sense, and plus, it's available on vercel domains. So here we are...

I also separated the documentation from the main app. I didn't really like having the landing page, dashboard, and docs all living together (personal preference), so I created a dedicated docs app in my monorepo and had my agents build out the UI.

You can find it at docs.tagviu.orashus.com.

I also had to update my Go CLI. Commands, printed outputs, naming... everything had to move from Trivue to Tagviu.

And because a trivueScore field was baked directly into my report database schema, I had to write a migration script for that as well..

One advantage of having fewer than 7 users on your platform is that you can get away with risky ahh, bold moves like these.

Among other things like video editing, I've been experimenting with Grok Bot. I decided to set up a new Tagviu X account and gave it access to this account.

I know... I know... it risks getting banned for bot activity. Trust me, I know.
It's been fun though.

I originally wondered who would actually pay for a metadata tool like this.

But it turns out, there are people on X who care about this stuff even more than I do. For some of them, especially the SEO experts, metadata inspection is literally part of their job, so yh, I just have to make Tagviu profitable...

Once I get payments figured out, I'll let the bot try to convince you to pay for Tagviu.

I'll also write about the payment integration problems I've been facing as a developer from Cameroon in a separate post and leave the link in the comments (It's geniunly sad fr).

For now, visit Tagviu and score your metadata, let your agent's use my mcp server to get you the best previews, embed your reports if you wanna brag about how healthy it is.

I 'm also open for suggestions.

https://tagviu.orashus.com

I Fumbled an Interview Not because I lack Technical Skills but an Arcade Development workflow

Rash Edmund — Thu, 10 Sep 2026 04:31:08 +0000

I just fumbled a casual interview with an organization a few hours ago.

It exposed a brutal truth:
Being technically competent is no longer enough by itself.
AI has changed the "developer skillsets". It's becoming less about how fast you can write code or how much syntax you can recall and more about how well you can:

Understand the problem
- Define clear requirements
- Architect the solution
- Use AI agents to implement it
- Review and validate the output

I was unable to impress my interviewer bcs I hadn't gone a step further by having a concrete agentic workflow to show them. A developmet workflow with AI so deep at it's core that most the work is automated and executed by agents.

I was unable to show them proper usage of agent skills, not the generic ones that come pre-written and budled as part of the cofigs of your AI IDEs, but mine, customized to my own specific needs.

I tried covering this up by talking about my private agent-resources github repo that has md files explaining how I build my nextjs apps, how I setup my services and repositories as factory functions with zod schemas and mappers to normalize db and input data and that my cursor has access to this github repository and uses a reference for my projects...

But that wasn't enough.
I believe I gave them the impression that I care abit too much about syntax and that smells of "Arcade programming which implies Slow delivery" in this AI era.

You see the pose in the cover photo above ? that's exactly how I sat down thinking about this.

That's the part I'm now paying more attention to.

I wrote a full breakdown on my blog. Link in the comments.

The Unbuffered Channels In Go Lesson I Think Has Finally Clicked for Me 🤷🏽‍♂️

Rash Edmund — Sat, 01 Aug 2026 15:45:46 +0000

While struggling to understand channels in go, I would try out many things in my sandbox repository.

I encountered deadlock errors and stuff about go routes being asleep.

I came to understand that the order of execution played a role and that with unbuffered channels you need a sender and a receiver ready at the same time (kind of).

I wrote a short article on my blog site about the experience

The Unbuffered Channels In Go Lesson I Think Has Finally Clicked for Me 🤷🏽‍♂️

The Market Isn't Just Competitive Anymore

Rash Edmund — Sat, 27 Jun 2026 13:06:17 +0000

There was a time when becoming a better developer mostly meant writing better code.

Today, that's no longer enough.

The market has become so competitive that developers are expected to wear multiple hats. You're not just an engineer anymore. You're expected to build a personal brand, create content, network with other professionals, contribute to open source, maintain an impressive portfolio, and somehow still keep up with the pace of technology.

Ironically, many of these skills have little to do with writing software itself.

Companies still hire engineers to solve technical problems, but getting noticed often depends on everything surrounding your technical ability. A well-written article, an active X profile, a conference talk, or an open-source contribution can sometimes create opportunities that another certification simply won't.

That doesn't mean technical skills have become less important. If anything, the technical bar is higher than ever. The difference is that being a great engineer is no longer enough to guarantee visibility.

The developers who stand out today often combine strong engineering skills with communication, consistency, and community involvement.

It's a difficult reality, especially for people who simply want to build software. But understanding the market is part of succeeding in it.

In many ways, software engineering has evolved beyond code. You're not only building products anymore, you’re also building trust, credibility, and a reputation that travels ahead of your résumé.

AI Is Exposing Technical Debt We Learned to Ignore

Rash Edmund — Fri, 19 Jun 2026 19:14:53 +0000

One thing I've noticed while working with AI tools is that they struggle with many of the same things junior engineers struggle with.

Not algorithms, and syntax, nor frameworks.

They struggle with ambiguity.

Give an AI vague requirements and you'll get vague results.

Point it at a codebase with inconsistent abstractions and it will make incorrect assumptions.

Ask it to work with undocumented business rules and it will confidently fill the gaps with guesses.

For years, teams survived these problems because people carried the missing context in their heads. New engineers asked questions. Senior engineers explained the history behind certain decisions. Knowledge spread through conversations.

AI doesn't have access to those conversations.

It only sees what's actually written down.

That's why, looking at some of the basic requirements for working with ai tools, I think AI is doing something unexpected: it's making software quality more visible.

A clean architecture isn't just easier for developers to navigate. It's easier for AI tools to understand.

Clear requirements aren't just good project management. They're becoming a prerequisite for effective AI collaboration.

The interesting lesson isn't that AI is imperfect.

It's that many of the things confusing AI were already confusing humans.

We just got used to working around them.

Why Most AI Features Fail After the Demo

Rash Edmund — Fri, 19 Jun 2026 07:01:48 +0000

Every week, a new product announces an AI feature.

A chatbot.
An agent.
A smart assistant.
An AI-powered search experience.

The demo looks impressive.

The launch gets attention.

Then six months later, nobody is using it.

Why?

Because building an AI feature and building an AI product are two completely different things.

The Demo Trap
Most AI features are designed for first impressions.

Ask a question.

Get a surprisingly good answer.

Share it on social media.

The problem is that real users don't interact with software the way demo videos do.

Real users are inconsistent.

They provide incomplete information.

They ask vague questions.

They expect reliability after the novelty wears off.

The gap between a successful demo and a useful product is much larger than many teams expect.

Intelligence Is Not the Product
A common mistake is treating the model itself as the product.

But users rarely care about the model.

They care about outcomes.

Nobody buys an email client because it uses a specific database.

Nobody chooses a ride-sharing app because of its backend architecture.

Likewise, most users do not care whether your application uses Gemini, GPT, Claude, or another model.

They care whether the system helps them accomplish a task.

The intelligence is infrastructure.

The product is the experience built around it.

Context Matters More Than Capability
A general-purpose model knows a lot.

A product needs to know the right things.

Consider two assistants:

The first can answer thousands of questions about almost anything.

The second only answers questions about your company, products, documentation, and support processes.

The second assistant is often more valuable despite being more limited.

Why?

Because it has context.

Users often prefer a focused assistant that consistently solves their problem over a powerful assistant that occasionally wanders into irrelevant territory.

Observability Is Underrated
One lesson many teams learn late is that AI systems need observability.

Traditional software gives predictable outputs.

AI systems do not.

If users are interacting with an assistant, you need visibility into:

What people are asking

Where responses fail

Which prompts create confusion

Which workflows are being abandoned

Without that feedback loop, improving the system becomes guesswork.

Guardrails Are Features
Many developers view restrictions as limitations.

In reality, constraints often improve the user experience.

An assistant that tries to answer everything usually performs worse than one with a clearly defined scope.

Users trust systems that behave predictably.

Sometimes the best response is not generating an answer.

Sometimes the best response is saying:

"I can't help with that."

The Future Belongs to Useful AI
The next wave of successful AI products will probably not be the most intelligent.

They will be the most useful.

They will have:

Clear boundaries

Strong context

Reliable behavior

Good observability

Thoughtful user experiences

The model will still matter.

But increasingly, the competitive advantage will come from product design rather than model selection.

The companies that understand this distinction will build products people continue using long after the demo ends.

The Most Dangerous Code in Your App Might Be a Fresh Dependency

Rash Edmund — Tue, 12 May 2026 11:46:48 +0000

The recent TanStack supply-chain compromise is a reminder that modern attacks are increasingly targeting the software delivery pipeline itself, not necessarily the frameworks or runtime code we use.

Their detailed post gives better insight into the impact, timeline, root cause, detection, and lessons learned: Read here.

A few practical mitigations are starting to feel less “optional” now:

minimum-release-age delays before installing newly published packages
stricter CI/publishing permissions
explicit package versions instead of broad ranges
verified publishing and provenance tooling

Yes, exact versions mean you manually handle patches and minor upgrades more often.

And minimum-release-age delays are not perfect either; they can also slow down urgent security patches.

But together, these measures help reduce the chance that a compromised package published minutes ago lands directly in production.

The ecosystem is entering an era where CI pipelines, package registries, publishing permissions, and dependency trust all need to be treated as part of application security.

If AI Writes the Code, Your Specs Become the Product

Rash Edmund — Wed, 06 May 2026 18:40:15 +0000

The question is no longer whether developers can write clean code.

The real question is: can we write specifications that machines can’t misunderstand?

As AI tools become part of everyday development workflows, the bottleneck is shifting. Code is no longer the hardest artifact to produce, rather clear, unambiguous intent is. When working with AI, vague requirements really don’t just slow things down, they tend to multiply errors at scale.

A human developer might pause to ask clarifying questions, An AI model won’t. It will confidently execute exactly what was written/promted; no more, no less.

Clean specifications are now a core engineering skill. They require:

Precision over assumption
Explicit constraints over implied logic
Structured thinking over informal descriptions

In many ways, writing specs for AI is closer to designing a contract than giving instructions. This is so beacause every ambiguity or missed edge case is a potential bug and failure.

The developers who thrive in this new environment won’t just be great coders, they’ll be "exceptional communicators of intent".
Because in an AI-assisted world, clarity is everything.