Coding Sniper @coding_sniper

@Ionkosm I lose my code..... and my job😆

@RashedatJ This has worked for me everytime: "If you die you die" Then deploy🥲

Getting ghosted by my crush is one thing. Getting ghosted by @paystack is another. 😭 @paystack, I’m starting to think you’re “visiting a friend.” 😂 Can you respond to my many emails??

Mostly Pesapal and Paystack promise quick onboarding. Mpesa has a long onboarding process and requirements as compared to the aggregators. One thing devs forget however is that even though onboarding is easy and fast, once money starts flowing they'll need you to submit what was skipped. It was just a delayed step

@cOcONOPUFFS Well they're buying time to find your replacement🥲

I still don’t know what Jev is.

I still can't get it why someone would pay for an SSL in 2026

@MGAWMC Dar??? Some streets utalala mteja bado.

Reminds me a lot of how I started my own journey. Back in campus, first year, I wanted to get into game development. Quickly realized it wasn't for me. Then I tried learning HTML + CSS by memorizing things. Couldn't get it. 😅 Eventually, I stumbled into HTML themes. I'd pick a template, modify the content, host it on GitHub, and convince myself I'd built a "company." I did make a few coins from local clients, though. I'd build websites for them, which was mostly just modifying templates. The first time I hosted a static website on HostPoa, I genuinely felt like a guru. 😂With time, things started clicking. Javascript animations. Then logins and databases. Vanilla PHP → CodeIgniter → Laravel. Along the way I wandered into Android Java, Flutter, Python, C#, CMSs... As a beginner without a mentor, you're pretty much all over the place trying everything. I eventually found my spot in Laravel. Then COVID hit. Now with quite good experience building web apps, got a client from UK who wanted me to build Covid cases tracker app. My first big project to deliver. Years later, I'm still building with Laravel, now with Go in the mix too. I've shipped quite a number of projects and consulted for startups. And all of that started with modifying HTML templates. Fast forward to 2026 and hardly anyone is starting that way anymore. They're vibecoding. But I don't think the curiosity has changed. The tool has. And I wouldn't be surprised if some of today's vibecoders, with enough curiosity, eventually start wondering: "Wait... how does this actually work?" That's where the real journey might begin.

khalif kairo @KhalifKairo

4 weeks ago

It actually happened by accident, last year i was depressed, broke and very frustrated on one Friday night. Clients kept calling ask for charter quotes and they’d never pay. So i asked myself, whats the laziest way i can do all this quotations and voila? Qcaero.app

4 9 155 23K 30

You're right, her name is Panigale V4.

$$$aįnt @brentswago

4 weeks ago

Men will never admit but their motivation to make money is always girls

1K 497 5K 816K 330

@_samurai93 Trust the process🤝

Working as a SWE consultant has taught me a lot. You really learn a lot in the wild. I built a payroll system for a client. I had to learn contracting structures, bonuses, accreditations, different tax bands, statutory deductions, leave management, and the compliance reports an HRM needs to generate. After that, I built accounting software. Now I learnt accounting; how each report is actually generated: the trial balance, P&L, balance sheet, cash flow statements, reconciliations. You see, you must understand something before you can ship it. Then there were the ERPs: inventory, procurement, supply chain, the works. And marketing systems too: pipelines, conversions, funnels, lead scoring, campaign attribution. And now I'm currently building an Enterprise Risk Management system. Boy, I had to learn risk registers, root cause analysis, risk scoring and heat maps, controls and control testing, treatment plans, and compliance reporting frameworks. Ain't consulting beautiful? I mean, you can't compare it to working in big tech or going deep in one specialization (dollar wise😆😆) but I've acquired a broad, general skill set just from building software across different domains.

Haha😂 it's just me, one guy, one laptop, way too much caffeine, not a company. I'm actually full-time employed elsewhere: part of an internal engineering team building and maintaining systems for an institution here in Kenya. I just built too much trust with some clients over time, so when I try to hand them off they refuse to let me go 😅 So nights & weekends, shipping in the dark like a caffeinated ninja.

Oh, and one detail I left out, every single one of those was shipped as SaaS. Not one-off builds. And therefore, with all that business logic, I also had to engineer for the architecture side of things: multitenancy, tenant isolation, white-labeling, and customizations to almost every flow. Because it's not just about understanding what a specific company does; it's about understanding the industry standard, the known constants, while still providing a default seeder for a default flow and settings, yet leaving room for my client's clients to customize everything. Some even "self-host," as they like to think when really it's just their own domain pointed at their tenant subdomain. You could literally open the same payroll system for two different clients and never know they're powered by the same codebase. Praise code! it actually makes me feel like a superhero.😆

Coding Sniper @coding_sniper

4 weeks ago

Working as a SWE consultant has taught me a lot. You really learn a lot in the wild. I built a payroll system for a client. I had to learn contracting structures, bonuses, accreditations, different tax bands, statutory deductions, leave management, and the compliance reports an

1 0 3 289 1

ikr😆 in my freelance era I always negotiated a support package into everything I shipped. Got a few clients on that. Years later, fulltime employed now, but cheques still land every 3 months without me lifting a finger. Under the hood, I built the systems to be self-sustaining: automated backups, monitoring & alerts, self healing on failure, auto patching for deps/CVEs, graceful retries, health checks. Built once, survives without me. Just monitoring & minor patches now, that's it. Sweetest money lol

The dust has settled on that PHP scalability thread. Good arguments were made on both sides, some real engineering got discussed, and one thing kept resurfacing: PHP still carries the same old label; can't handle real traffic, doesn't scale. Worth actually dissecting that. For context, I work across Go and Laravel, picking based on the problem, team, budget, workload, timeline. Not a loyalty thing either way. Both have earned their place on different projects I've shipped. This is not a PHP vs Go post, rather it's a look at how far PHP can actually be pushed when it's built with intent, not left running on defaults from a decade ago So, can PHP actually take serious load? Here's where the reputation comes from, and where it's outdated. Most PHP apps run behind PHP-FPM: a pool of worker processes, one process per request. A request comes in, a worker boots the app, handles it, then throws away everything, no memory of the last request, no connection kept open. Clean isolation, but it means every worker opens its own fresh DB connection on every single request. Stack enough workers across enough hosts under load and you can blow past DB connection pool limit, well before the DB itself is actually struggling. That's mostly the argument behind most PHP can't scale stories, an architecture issue one layer below the language, not a language ceiling. Fixing it takes real work, not one setting flip. Here's what that work actually looks like: Bytecode caching plus the JIT compiler (both standard in PHP 8) Remove most of the cost of re-parsing and re-interpreting a request from scratch every time it lands by caching compiled configs, routes, and views instead of rebuilding them on every boot. This alone kills a big chunk of the "PHP is slow" reputation, and it's free once it's turned on. Long-lived worker runtimes change the deeper problem. Tools like Octane and FrankenPHP keep the application booted and resident in memory across many requests instead of rebuilding it cold every single time; closer to how a long-running Go or Node service behaves. Swoole takes it a step further, giving PHP real coroutines (cooperative, non-blocking concurrency within a single worker) closer to an actual event-loop model rather than just a long-lived process. Worth noting; FrankenPHP itself is literally built in Go, wrapping the PHP runtime. The database connection issue gets solved the same way any connection-hungry stack solves it: a pooling layer sitting between the app and the database, so the real number of connections MySQL or Postgres actually sees stays bounded no matter how many workers or hosts you add on the app side. Queues take the heaviest work out of the request/response cycle entirely. Accept the request, acknowledge it, and let a background worker handle the expensive part. This also removes most of the pressure that scaling conversations usually obsess over. Once the runtime itself stops being the bottleneck, the database usually becomes the real one, and that's solved with read replicas for read-heavy load, caching layers in front of hot queries, and sharding for write-heavy workloads that would otherwise all serialize on one primary. None of this is PHP-specific; every language hits this same wall eventually. And the cheapest request is always the one that never reaches your application at all. CDNs, full-page caching, and edge logic strip out a large share of traffic before it ever touches a PHP worker. None of this is exotic, and none of it means ditching the language. It means treating scale as an architecture problem which it is, in every stack instead of assuming the runtime itself is the ceiling. So FPM's limits are real, well documented, and not community propaganda. The criticism is accurate for that specific deployment model. Modern PHP closes most of that gap, but that calls for a deliberate architecture, not a config flag, and I won't pretend otherwise just to defend the language. What isn't fair is treating PHP as automatically disqualified from serious scale in 2026 when the actual failure mode being pointed at is a decade-old deployment default, not the language as it exists today. Appreciate everyone who engaged in good faith. I learned more from the pushback than I would have from either side just winning. @kevvOH_ @_samurai93

@kevvOH_ Did you consider alpine + multi-stage builds?Image bloats when you use the full base, bake in Composer dependencies,leave dev extensions on etc.But Go compiling to a single static binary with no runtime, interpreter, or extension loading is an arch advantage no PHP tuning closes.

@kevvOH_ The move is justified. I love Go too.I use both, based on the problem. I just feel PHP gets judged harshly, often branded unscalable, when modern PHP can actually go toe-to-toe with most stacks. I always love these discussions to show devs PHP is scalable, just not zero-effort.

@kevvOH_ fair, bt you actually raised this earlier when you said DB connections will be at risk. But I agree octane workers block per request. However, Swoole coroutines give PHP cooperative, non-blocking concurrency within a worker, closer to Node's single-threaded event-loop model.

@kevvOH_ You'd need unreasonable worker count to hit the same wall. Either way when you decide to scale workers horizontally; then put a pooling layer between the app and the DB so the no. of real database connections stays bounded no matter how many application workers or hosts you add.

@kevvOH_ FPM does have that problem: every worker spawns a connection and kills it on process end, so connection count scales with worker × host count.Octane doesn't work that way though. Workers are long-lived and reuse their DB connection across many requests