So last week a military drone blew up the AWS data center where my customer’s platform runs. The platform serves millions of users across seven countries. I had to spend about a week moving everything from Bahrain to Europe. By hand. Because every single automated migration tool was also broken. Because, you know, the drones.

I run a software consultancy. I’ve been in tech long enough to have planned for almost every disaster imaginable. Floods, earthquakes, ransomware, that one guy who drops the production database on a Friday afternoon. “Military drone strike on your cloud provider” was never on the list.

And Bahrain is not an isolated case. Right now, data centers in more than ten countries are being targeted or threatened by either Iranian or russian drones. This isn’t a regional incident. It’s a global pattern.

And yet, here we are. Welcome to DevOps in 2026.

Disaster Recovery Used to Mean Hurricanes. Now It Means Drones.

If you’ve worked in infrastructure long enough, you’ve imagined the disaster scenarios. An earthquake takes out a data center in Tokyo. Hurricane floods a facility in Virginia. Maybe a biblical-scale power outage somewhere in Texas (actually, that one happens pretty regularly). You build for resilience, you plan your failovers, you sleep slightly less terribly at night.

And I don’t say “earthquake” lightly. Exactly a year ago, my wife and I were on the top floor of our skyscraper condo in Bangkok when a 7.7 magnitude earthquake hit. One second I was pushing a commit. The next second I was crawling on the floor. The building was swaying two meters each side, and water from the rooftop pool came crashing through into our living room. I still get flashbacks from that. So yes, I understand natural disasters on a very personal, visceral level. I expected those to be the thing that would eventually force me to move servers under pressure.

What I never rehearsed was: “Your entire AWS region is down because a military drone hit all availability zones in Bahrain.”

Yet here we are.

In early March, Iranian drones struck multiple AWS facilities across the UAE and Bahrain. This wasn’t some theoretical threat model from a security conference whiteboard. This was the first confirmed military attack on a major hyperscale cloud provider’s infrastructure. Banking apps went down. Payment systems collapsed. Delivery platforms across the Gulf went dark. And somewhere in Thailand, my phone started buzzing with messages from a very worried customer in Saudi Arabia.

There’s No Terraform Module for Surviving a War Zone

Here’s what you need to understand about the week that followed: every single automated migration tool AWS provides was broken. CloudWatch, the thing that tells you if your servers are even alive? Gone. RDS Snapshots, the thing you use to back up databases before you touch anything? Unavailable. Cross-region transfer? Dead. AMI copies? Nope.

It was like showing up to a house fire and discovering that not only is your fire truck empty, but someone also stole the hydrant.

So I did what any reasonable engineer would do. I had to rebuilt multiple production environments from scratch, on bare Linux images, in Europe. By hand. For a platform serving millions of users across seven countries. I wrote custom scripts to export, compress, and transfer everything over the public internet (because AWS’s own internal backbone between regions was also down). I wrote manual rescue scripts for files that kept failing for days with InternalError. I worked nights because often it was the only window where platform traffic was low enough to safely verify everything.

One week of controlled chaos. And by the end of it, the entire platform was running smoothly from Europe, as if nothing had happened.

But everything had happened.

We’re a Software Company. Why Do We Keep Running From Wars?

I could tell this story as a purely technical narrative. Here’s the architecture, here’s the migration plan, here’s the clever script that saved the day. But that would miss the point entirely.

Because here’s what my day-to-day actually looks like:

I run a small tech consultancy. We build custom software. We manage cloud infrastructure. We automate businesses with AI workflows. Very normal stuff. And yet somehow, every single person on my team has been touched by war. Not metaphorically. Literally.

I live in Thailand, which recently had skirmishes with Cambodia along the border. My Iranian engineer had to flee Iran with his entire family. One of my coworkers lives in Ukraine, literally in a war zone, delivering code between power cuts because the grid keeps getting hit by Iranian-designed drones. A couple of months ago he went to an immigration office across the border and couldn’t come back for days because russians bombed the only bridge on his route home. Another colleague had to evacuate Ukraine with his whole family.

We write code and configure servers. We’re not defense contractors. We’re not geopolitical analysts. We’re developers who just want to ship clean code and go home.

And yet, every week, somewhere on this planet, a conflict reaches through the internet cables and grabs us by the collar.

The Strangest Plot Twist of 2026

And now, in what might be the most unexpected geopolitical crossover episode of the decade: Ukraine is protecting Saudi skies.

Let that sink in for a second. The country that has been fighting for its own survival since 2022, that has become the world’s foremost expert on shooting down drones because it had no choice, has just signed defense cooperation agreements with Saudi Arabia, Qatar, and the UAE. Over 200 Ukrainian drone-countering specialists are now deployed across the Gulf, helping defend the very region where my customer’s servers used to live.

The same drones that forced me to migrate infrastructure out of Bahrain? Ukraine knows those drones intimately. They’ve been dealing with their Iranian-made cousins, the Shaheds, for years.

So now the country of my colleague who codes between blackouts is also the country protecting the airspace above my customer’s business. If you wrote this as fiction, your editor would tell you it’s too on the nose.

Who Else Is Living This?

I can’t be the only one. There must be thousands of engineers, sysadmins, CTOs, and DevOps folks out there who have spent the last few years making decisions that no technical manual covers. Moving workloads because of missiles. Rerouting traffic because of sanctions. Keeping systems alive through infrastructure that’s being actively targeted.

If you’ve had to migrate production systems because of armed conflict, I’d love to hear your story.

The New Normal (Which Is Not Normal At All)

Twenty years ago, your biggest infrastructure worry was a hard drive failing or router dropping packets. Ten years ago, it was maybe a ransomware attack. Today, it’s a state-sponsored drone strike on your cloud provider’s physical data center.

We’ve entered an era where “disaster recovery” needs to account for actual disasters of the military kind. Where your multi-region strategy isn’t just about latency and compliance, it’s about geopolitical risk assessment.

The conflicts we see on the news aren’t happening “over there” anymore. They’re happening inside our dashboards, our uptime monitors, our incident channels. Every single one of us in tech is connected to these events whether we like it or not.

The world got very small, and very complicated, very fast.

Originally published at https://dawidmakowski.com on March 31, 2026.

You Put OpenClaw on a VPS. It Has Access to Everything. You Secured None of It. Let’s Fix That in 30 Minutes.

This guide was written for the brave souls who saw the OpenClaw hype train, jumped aboard, spun up their first VPS, and then had the terrifying realization that they now need to learn Linux security. You’re going to be fine. Probably.

Look, I get it. You saw the hype. You saw the tweets. You saw some guy on Reddit say OpenClaw changed his life, and now you’re sitting there at 2 AM with your very first VPS, a fresh install of OpenClaw, and the sudden realization that you just handed an AI assistant the keys to your email, your calendar, your Google Drive, your private documents, and basically your entire digital soul — all running on a server you’ve never secured before because, well, this is your first server.

Now, let’s be fair: a fresh Ubuntu installation isn’t actually a house with no doors. Ubuntu ships with sensible defaults — no unnecessary open ports, no sketchy services running, SSH with reasonable settings. Credit where credit is due. But here’s the problem: you’re not running a fresh Ubuntu installation anymore. You’re running OpenClaw on top of it. With plugins. And skills. And extensions. And API keys to everything you own.

Here’s a fun fact to help you sleep tonight: every VPS that connects to the internet gets fully port-scanned by automated bots within 10 to 20 minutes. Not hours. Not days. Minutes.

But with OpenClaw and its ecosystem of plugins exposing additional services and APIs? Now you’re interesting. And on the internet, you do not want to be interesting.

And look — I’m not here to trash OpenClaw. It’s genuinely cool. The AI-assistant-on-your-own-server dream is alive and well. But let’s be honest with ourselves for a moment: OpenClaw, plus all of its plugins, skills, and extensions, is not exactly what security researchers would call “airtight.” It’s more what they’d call “a fun afternoon.” The platform is young, moving fast, and the attack surface grows with every skill you install. The real risk isn’t Ubuntu’s defaults — it’s everything you’re bolting on top of them.

So since we can’t fix OpenClaw’s security overnight, let’s make damn sure that the server underneath it is locked down tight, so that even if someone finds a vulnerability in a plugin, they hit a brick wall instead of a buffet.

The good news? I recommend Ubuntu for your VPS, and I’m going to walk you through this whole thing step by step.

Why Ubuntu? Because it has a massive community, a mountain of security tools, and — this is the important part — any non-technical noob can harden it in about 30 minutes with proper guidance.

Let’s go. And please, for the love of everything, don’t close your terminal until I tell you to.

Step 0 — Non-root user

Before we do anything else — if you’re still logged in as root like some kind of digital cowboy, we need to fix that immediately. Root is the god account. It can do anything, break anything, and delete anything, including itself.

So let’s create a proper user and give it sudo powers:

adduser ubuntu usermod -aG sudo ubuntu

Now, because typing your password every time you run sudo gets old approximately 4 seconds after the first time, let's set up passwordless sudo. Run visudo and add this line at the very bottom:

ubuntu ALL=(ALL) NOPASSWD:ALL

From this point on, you do everything as ubuntu and use sudo when you need elevated privileges. Think of root as the emergency fire axe behind glass - it's there if you need it, but you shouldn't be casually swinging it around on a Tuesday afternoon.

Now copy your SSH key to the new user ( ssh-copy-id or manually paste it into /home/ubuntu/.ssh/authorized_keys), log in as ubuntu in a new terminal to make sure it works, and never log in as root again.

Step 1: Set Your Timezone

Before we do anything dramatic, let’s make sure your server knows what time it is. This sounds trivial, but accurate timestamps in your logs are the difference between “I can see exactly when someone broke in” and “something happened… at some point…

dpkg-reconfigure tzdata

Pick your timezone from the menu. It’s interactive.

Step 2: Update Everything

Your server shipped with software that was already outdated by the time you clicked “Deploy.” Let’s fix that.

apt update && apt upgrade -y

This updates all your packages to their latest versions, patching known vulnerabilities. Think of it as putting on pants before leaving the house. Bare minimum.

Now, because we both know you’re going to forget to do this regularly (I know you, and I love you, but I know you), let’s set up automatic security updates:

apt install unattended-upgrades -y sudo dpkg-reconfigure --priority=low unattended-upgrades

This configures your server to automatically install critical security patches without you having to remember. It’s like hiring a tiny robot butler whose only job is to lock the doors you keep leaving open.

Step 3: Set Up Ubuntu Pro

Ubuntu Pro gives you expanded security maintenance, kernel live patching, and compliance tools. And here’s the kicker — it’s free for up to 5 machines.

Go to ubuntu.com/pro, grab your token, and attach it:

pro attach YOUR_TOKEN_HERE

This extends your security coverage and covers thousands of additional packages. It’s like getting the extended warranty, except it actually does something.

Step 4: Lock Down SSH

SSH is how you talk to your server. It’s also how everyone else tries to talk to your server. By default, it’s running on port 22, which is the first port every bot on the internet checks. That’s like hiding your house key under the doormat — the one place literally everyone looks first.

Edit your SSH config:

nano /etc/ssh/sshd_config

Here’s what your config should look like. I’ll explain each line, because I respect you and your journey:

Port 55222 # Move SSH off the default port. Not foolproof, but stops 90% of really lazy scanners. LoginGraceTime 2m # You get 2 minutes to authenticate. After that, goodbye. PermitRootLogin no # NOBODY logs in as root. Ever. Not even you. Especially you. MaxAuthTries 5 # 5 wrong passwords and we hang up on you. Rude? Maybe. Secure? Yes. PasswordAuthentication no # No passwords. Period. Keys only. Passwords are the cargo shorts of security. PermitEmptyPasswords no # Just... no. Come on. AllowUsers ubuntu # Only the 'ubuntu' user can log in. Everyone else can go home. X11Forwarding no # No graphical forwarding. This is a server, not a gaming PC. PermitUserEnvironment no # Don't let users set environment variables through SSH. Trust issues? You bet. AllowAgentForwarding no # No SSH agent forwarding. Reduces the risk of key theft. AllowTcpForwarding no # No TCP tunneling through your server. It's not a VPN. PermitTunnel no # Same energy as above. No tunnels. KbdInteractiveAuthentication yes # Needed for 2FA (we'll get there, be patient). ChallengeResponseAuthentication yes # Also needed for 2FA. The dynamic duo. AuthenticationMethods publickey,keyboard-interactive # Key first, then 2FA code. Belt AND suspenders. UsePAM yes # Use PAM for authentication. Required for Google Authenticator.

The key takeaways: We moved the SSH port (so bots can’t find it easily), disabled root login (so even if someone gets in, they’re not god), killed password authentication (keys only, like a VIP club), and set up the groundwork for two-factor authentication.

Now reload SSH so it actually pays attention to what we just told it:

sshd -t && systemctl reload ssh.service

The sshd -t part tests your config first. If there's a typo, it'll tell you before you lock yourself out. Because locking yourself out of your own server is a very special kind of pain.

⚠️ CRITICAL: Do NOT close your current terminal session yet. Open a NEW terminal and test that you can still connect with your new settings before closing anything.

ssh -i /path/to/your-key -p 55222 ubuntu@your-server-ip

Step 5: Install Fail2Ban

Fail2Ban watches your authentication logs and automatically bans IP addresses that fail to log in too many times. It’s basically a nightclub bouncer for your server.

apt install fail2ban -y

Out of the box, Fail2Ban will monitor SSH and ban anyone who fails authentication repeatedly. You can customize the jail settings later, but the defaults are already pretty solid for keeping the riff-raff out.

Think of it this way: Step 4 made it harder to get in. Step 5 makes sure that anyone who keeps trying gets permanently shown the door.

Step 6: Set Up Two-Factor Authentication

This is the big one. This is where we go from “pretty secure” to “okay, now I can actually sleep at night.”

Two-factor authentication means that even if someone somehow gets your SSH key (it happens — laptops get stolen, backups get leaked, your cat walks across your keyboard and emails it to someone), they STILL can’t get in without the 6-digit code from your phone.

Install Google Authenticator:

apt install libpam-google-authenticator -y

Switch to your ubuntu user and run the setup:

su - ubuntu google-authenticator

It’ll ask you some questions. Here are the correct answers (you’re welcome):

It’ll show you a QR code. Scan it with Google Authenticator, Authy, or whatever TOTP app you prefer. And for the love of all that is holy, SAVE THE EMERGENCY SCRATCH CODES.
Put them in a password manager (important!). They’re your “break glass in case of emergency” codes if you lose your phone.

Configure PAM (this tells SSH to actually use the authenticator):

sudo nano /etc/pam.d/sshd

Add this line at the very top:

auth required pam_google_authenticator.so

And comment out this line (to prevent a double password prompt, which is annoying and unnecessary):

# @include common-auth

Make sure your SSH config has these lines set correctly (most of them should already be right from Step 4):

KbdInteractiveAuthentication yes ChallengeResponseAuthentication yes AuthenticationMethods publickey,keyboard-interactive UsePAM yes PasswordAuthentication no

Test the config and restart SSH:

sshd -t && systemctl restart ssh

Now test in a NEW terminal (seriously, keep your current session open — are you sensing a pattern here?):

ssh -i /path/to/your-key -p 55222 ubuntu@your-server-ip

Your login flow should now be: SSH key → TOTP verification code → you’re in. No password involved. Just your key and your phone. It’s like a secret handshake, but actually secure.

Step 7: Monitor Your Logs

Congratulations, your server is now significantly more secure than it was 20 minutes ago. But you need to actually check on things occasionally.

Check your SSH authentication logs:

sudo cat /var/log/auth.log | grep sshd

For live monitoring (great for watching scans/attacks happen in real-time, which is weirdly entertaining):

sudo tail -f /var/log/auth.log

What to look for:

• Repeated failed login attempts — Fail2Ban should catch these, but check anyway
• Login attempts from unfamiliar IP addresses — If you see IPs you don’t recognize, investigate
• Unknown usernames — If someone’s trying to log in as “admin” or “test,” that’s a bot
• Successful logins at weird hours — If you logged in at 3 AM and you were asleep at 3 AM, we have a problem

Bonus Round: For the Ambitious

If you’ve made it this far and you’re feeling confident (possibly too confident, but I respect the energy), here are two next-level options:

Tailscale

Tailscale creates a private mesh VPN between your devices. Once set up, you can access your server through a private network that isn’t exposed to the public internet at all. It’s like having a secret tunnel to your server that only you know about. The setup is shockingly simple for something this powerful.

Cloudflare Tunnel

Cloudflare Tunnel lets you expose your OpenClaw instance to the internet without opening ANY inbound ports on your server. Zero. None. The server reaches out to Cloudflare, and Cloudflare handles all incoming traffic. It’s like having a P.O. Box for your server — people can send you mail, but they don’t know where you live.

Both of these are excellent options if you want to take your security from “solid” to “paranoid, but like, in a healthy way.”

Final Thoughts

If you’re running OpenClaw on a VPS, you’ve put your most private digital life on a server connected to the open internet. Your emails. Your calendar. Your documents. Your credentials. All of it sitting there, protected by whatever security you bothered to set up.

Is your server now impenetrable? No. Nothing is impenetrable. But you’ve gone from being a soft, delicious target to being the server that’s maybe not worth the effort today when there are millions of easier ones to hit.

You’ve got this. Probably. I believe in you. Mostly.

Originally published at https://dawidmakowski.com on February 24, 2026.

I’ve watched the same movie play out too many times: a management team receives a penetration testing report, sees a wall of findings with scary-sounding names, and immediately assumes their platform is on fire.

It’s not on fire. It’s almost never on fire.

But the report sure makes it look like it is. And that’s the problem I keep running into — not with the platforms, but with how people read these reports.

The Translation Problem

When you’re a CTO or an external CTO-as-a-Service advisor, part of the job is translating between the world of security tooling and the world of business decision-making. These two worlds speak very different languages. Security tools speak in volumes of automated findings. Business leaders speak in risk, cost, and “should I be worried right now?”

That gap is where the panic starts.

Over the years I’ve learned to get ahead of it. Before every VAPT (Vulnerability Assessment and Penetration Testing) cycle, I walk my clients through what to expect from the results — what the findings actually mean, what’s noise, and what deserves real attention. It’s part education, part expectation management, and part gentle reminder that a 200-page PDF full of findings does not mean the sky is falling. Sometimes it just means the scanner was very thorough and a bit too enthusiastic.

The goal is simple: give non-technical stakeholders the mental framework to read a VAPT report without losing sleep. Because the report is only half of the story. The other half — the part that actually matters — is interpreting those findings in the context of your platform, your architecture, and your specific business requirements.

The Anatomy of a VAPT Report (For Humans)

Here’s what most people don’t realize about penetration testing: the raw output of any engagement is never the final verdict on your security. It’s a starting point for analysis.

VAPT teams rely on automated scanning tools to generate their initial findings. These tools are designed to cast an absurdly wide net. They flag anything that could theoretically be a concern. And I mean anything. Your OAuth integration with Google? Flagged. Your CDN serving static assets from a different domain? Flagged. A cookie that JavaScript can access because your entire framework was literally designed that way? You better believe that’s flagged. Any open port on the server, even port 80 or 443? Yup, also flagged.

This isn’t a flaw in the process. It’s how the process works. The tools are doing their job. The question is what happens next.

The Quality Gap Nobody Talks About

And here’s where it gets interesting.

Not all VAPT teams are created equal. In fact, there’s a pretty dramatic quality spectrum, and where your team falls on it determines whether you receive a useful, contextualised security assessment or a PDF-shaped anxiety attack.

Budget-oriented teams tend to optimise for volume. They run the tools, collect the output, and forward everything to the client with minimal filtering. The result? A report with dozens — sometimes hundreds — of findings, many of which are informational noise or outright false positives. It looks impressive. It fills a lot of pages. But it creates exactly the kind of alarm that derails productive conversations about actual security.

I’ve seen reports where the same exact finding was listed separately for every URL on the platform. Same issue, same root cause, same “vulnerability” — just presented 147 times to make the PDF thicker.

More experienced teams — and yes, they typically cost more — invest significant effort in triaging their tool output before presenting it. They separate signal from noise. They tell you what actually matters and why. They cross-reference previous engagement results instead of re-investigating known behaviours from scratch. Their reports are shorter, more accurate, and infinitely more useful. You’re paying for judgment, not just scanning hours.

Severity Levels: A Quick Decoder Ring

Every VAPT report categorises findings by severity. Here’s the practical translation:

Critical and High — Stop what you’re doing and fix these. These represent real, exploitable vulnerabilities. In a well-maintained platform with regular dependency updates, strong authentication, and proper encryption, these should be rare. If your report is full of them, you have a genuine problem. If it has zero, congratulations — that’s the goal.

Medium and Low — Read these with a calm mind. They often represent theoretical risks, hardening suggestions, or configuration preferences. Many are informational. Think of them as a security consultant saying “you could also do this” rather than “your house is currently on fire.”

Informational — These are diagnostic notes. They describe how your platform behaves. They don’t indicate risk. You can acknowledge them and move on.

The number of findings in a report tells you almost nothing about how secure your platform is. A report with 150 findings and zero criticals is a dramatically better result than one with 5 findings and 2 criticals.

False Positives: The Uninvited Guests

Every — and I mean every — VAPT engagement produces false positives. These are findings that automated tools flag as potential issues but which, upon analysis, turn out to be expected framework behaviours, design decisions, or artefacts of the cloud infrastructure itself.

In a recent engagement, we documented over 20 false positives across two reports. The cloud provider’s own security infrastructure was triggering alerts during the scan — the scanning tools were essentially detecting the host’s defence systems and reporting them as application vulnerabilities. That’s like a home inspector flagging your alarm system as a security risk. Technically, something happened. Practically, it’s the opposite of a problem.

Context Is Everything

If there’s one thing I want people to take away from this, it’s this: a VAPT report must always be read in the context of the specific platform it was conducted against.

Security is not a one-size-fits-all discipline. A finding that represents a genuine vulnerability on one platform could be an intentional design decision on another. Session tokens in URLs? Alarming — unless they’re part of a standard OAuth handshake with a provider like Google or Twitter, in which case they’re temporary, scoped, and exactly where they’re supposed to be. Cross-domain script includes? Suspicious — unless they’re loading Google’s reCAPTCHA or your SSO integration, in which case they’re essential.

The report is half of the truth. The contextual analysis is the other half. Without both, you’re making decisions based on incomplete information — and in my experience, those decisions tend to lean toward unnecessary panic and wasted remediation effort.

If you have a VAPT cycle coming up, prepare your stakeholders before the report lands. It’ll save you a week of damage-control conversations that didn’t need to happen.

Originally published at https://dawidmakowski.com on February 17, 2026.

I’ll let that sink in for a moment.

The platform everyone was losing their minds over last week, the one Andrej Karpathy called “the most incredible sci-fi takeoff-adjacent thing” — just had its entire database cracked open.

Wiz published a brilliant breakdown of how they did it (link below), and the punchline is almost too good: their advanced hacking technique was looking at the JavaScript. That’s it. That’s the penetration test.

Here’s what was sitting there, unprotected, like a diary left open as chope at the hawker center:
- 1.5 million API authentication tokens
- 35,000 email addresses
- Thousands of private messages between “agents”
- Plaintext OpenAI API keys that users shared in DMs (yes, plaintext, in 2026)
- Full read AND write access to the entire production database

The root cause? A Supabase API key hardcoded in client-side JavaScript with zero Row Level Security configured. For non-technical folks: that’s like locking your front door but leaving the key taped to it with a sticky note that says “PLEASE DON’T USE THIS.”

But wait — it gets better.

The platform claimed 1.5 million AI agents. The database revealed 17,000 actual humans behind them. That’s an 88:1 ratio. No rate limiting. No verification whether an “agent” was actually AI or just a guy with a for loop and a free afternoon. The revolutionary AI social network was largely… humans pretending to be bots pretending to be autonomous, controlling bots.

The creator publicly said he “didn’t write one line of code.” The entire platform was vibe-coded. And look — I love AI-assisted development. I use it daily. But there’s a difference between using AI to write code and using AI to replace understanding what your code does.

Vibe coding without security review is like building a bank out of cardboard because it went up really fast.

This is not an edge case. This is the pattern. Every few weeks we see another vibe-coded app shipped to production with the security posture of a weekend hackathon project — except this time it’s handling millions of API keys and real user data.

The lessons aren’t new. They’re embarrassingly old:
- Don’t hardcode secrets in frontend JavaScript
- Enable Row Level Security if you’re using Supabase (it exists for a reason)
- Rate limit account creation
- Don’t store credentials in plaintext
- If you vibe-code it, at least have someone who understands security review it before launch

None of this is cutting-edge advice. It’s the basics. It’s chapter one. And somehow we keep skipping it because shipping fast feels more important than shipping safe.

Fixing vibe-coded apps is literally what my team does for a living. We audit, patch, and harden applications that were built fast but need to be built right. Drop me a DM if you want us to take a look at your app.

Full technical breakdown by Wiz: https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys

An interview should never feel like a test. It should feel like a sales call where your questions lead the way.

If you are a candidate, you need to ask more questions than you are asked. The company is not your examiner. It is your potential customer.

Think like a salesperson. Build a relationship. Show that you care. And yes, I just had to write this after the recent round of interviews because I really hate boring ones.

The Painful Pattern of Silence

I interview 10 to 20 people every month, mostly for technical roles. The most painful pattern is silence. I’m speaking with smart, capable adults who still walk into interviews with a school exam mindset.

I ask candidates to ask questions at least twice. First after I present the project and the client. Then again towards the end of the conversation. I even spell it out: you can ask me about anything, not just the job, please.

And yet, most often I still hear crickets. That is the worst-case scenario for the candidate.

Why Questions Matter More Than Answers

The number of questions should be balanced on both sides. That is how you create a real conversation. If the candidate asks more questions than the interviewer, that is even better.

Most interviewers do not expect to answer more questions than they ask. Which is exactly why the candidates who do it stand out.

Because asking questions is how you leave a lasting positive impression. It is how you sometimes open doors you did not even know were there. Maybe you land the job. Maybe you get recommended for a different one that fits you better.

So do not just show up ready to answer. Show up ready to ask.

What is the best question you have ever asked in an interview or wish you had?

Originally published at https://dawidmakowski.com on September 24, 2025.

There’s a lot of hype about vibe coding -that moment when caffeine hits, your playlist slaps, and you hammer out code like a jazz drummer sprinting through a solo. It’s exhilarating, but relying on that adrenaline burst is like funding your retirement with scratch-offs.

So let’s flip the script to something that actually compounds: vibe refactoring. Same spontaneous energy, but aimed at shrinking technical debt and sharpening your architecture instead of amping up the commit count.

https://www.youtube.com/watch?v=M8WdXRuzHvU

A Quick Setup

Block 15–20 minutes on your calendar. No ticket, no KPI, no “reduce cyclomatic complexity by 13.7 %” targets. Just a promise to poke around your codebase with beginner eyes.

Step-by-Step (a.k.a. How the Magic Happens)

1. Open the IDE and wander
   Pretend you cloned this repo yesterday. Warnings and TODOs suddenly look less like background noise and more like neon signs that say “Fix me, champ.” Clear a few of those-you’ll feel lighter already.
2. Let the IDE nag you
   Hover over the yellow squiggles. Remove the unused imports, tame the long methods, rename the variable that’s secretly been haunting you since 2019. Each micro-win is a quick dopamine hit.
3. This bundles context so large-language models can actually understand your project’s ecosystem instead of hallucinating a new service layer “for funsies.”
4. Chat with an LLM
   Drop a knotty function into your favorite model and ask:
   “Any cleaner way to handle this?” or
   “Spot an N+1 query?” or
   “Got an indexing tip for this desperate JOIN?”
   It’s brutally honest rubber-duck debugging-and it never rolls its eyes.
5. Follow the rabbit hole
   A “quick” fix often blossoms into a two-hour code spa. Let it. Today’s detour is tomorrow’s velocity boost.

What You’ll Gain (Besides a Self-Esteem Spike)

• Compounding quality: Tiny weekly tweaks snowball into major stability over months.
• Faster deployments: Fewer regressions means release day stops feeling like Russian roulette.
• Happier teammates: A clean codebase is onboarding heaven-no more haunted-house tours for new hires.
• Satisfied customers: Snappier queries and smoother UX, even if they can’t pinpoint why things suddenly feel better.

Keep It Light, Keep It Weekly

No formal goals, no pressure. Cue your favorite playlist, celebrate micro-wins in Slack (GIFs encouraged), and rotate refactor buddies so fresh eyes stay fresh. This is maintenance rebranded as exploration-curiosity, but profitable.

Final Thought

Vibe coding gives you adrenaline.
Vibe refactoring gives you longevity.

Block the time, wander through the code, and watch the compound interest kick in. Do it once and you’ll feel lighter; do it every week and you’ll wonder how you ever shipped without it.

Originally published at https://dawidmakowski.com on April 26, 2025.

More than a decade ago, I had the opportunity to take a Total Quality Management (TQM) course by none other than Andrzej Blikle at ASBIRO, a unique Polish educational institution where only entrepreneurs teach entrepreneurship.

Since then, I’ve been testing and refining various TQM techniques with my teams, especially in the startup world. I’m sharing some of my observations and ideas I’ve implemented, with a focus on weekly Kaizen-style sessions, which have proven effective in a variety of real-life scenarios within our teams.

Andrzej Blikle is a prominent Polish entrepreneur, well-known for his work in quality management and as the leader of the Blikle family confectionery business, which is famous for creating iconic and irresistible Polish “ A.Blikle donuts “ (pączki). He has expanded the company while preserving its legacy, transforming it into a modern, quality-driven organization.

Total Quality Management (TQM) is a comprehensive, organization-wide approach focused on continuous improvement and long-term success, involving all members of the organization. Kaizen, on the other hand, is a specific technique within TQM that emphasizes making small, incremental improvements on a daily basis to enhance processes and eliminate inefficiencies. The key takeaway was that for any organization to thrive, it needs to evolve continuously with the contributions of all its members (management included).

In the fast-paced world of tech startups, where ideas flood in and deadlines loom, it’s easy to lose sight of the bigger picture. When you’re buried in daily tasks like coding and designing, managing large-scale projects can feel overwhelming. With product teams often numbering in the dozens, it’s essential to have methods in place to maintain both product quality and an efficient software production process.

It wasn’t until about 10 years ago that I introduced weekly Kaizen-format meetings to all my teams. I wanted something simple but impactful. These meetings became a cornerstone of our process improvement journey. Why? Because they allow for consistent feedback and provide a platform for team members to raise issues that, if left unchecked, might snowball into larger problems.

Here’s how it works: every week, I bring together all members of my product and tech teams. No silos. The last day of the week usually works best. Developers, designers, product managers — everyone. The goal is to give them a space to vent, to share their frustrations, and to point out obstacles that hinder progress. And no, it’s not a “let’s complain about the boss” session. We focus on real, actionable issues.

A simple question like “What are you complaining about this week?” opens the door for all kinds of insights. It’s the best way to start a conversation because it allows everyone to express their concerns, whether it’s about the process, communication issues, or even something as trivial as a lack of coffee in the office. I literally used to remind people every week: “We have a kaizen session on Friday, each of you — bring your complaints please!”.

Why not just ask for improvement ideas first, right? Well, here’s where it gets a bit counterintuitive. Asking people to propose improvements can often lead to more question marks than solutions. From my experience, the ideas you get from this question tend to be more “nice-to-haves” rather than actual problems. It’s only after you’ve had a few months of these sessions with your team, and everyone is on the same page, that you can start throwing this question around. By then, people are already coming up with improvement ideas on their own — you don’t even need to ask.

At first, convincing people to participate in candid discussions can be challenging, especially in cultures where openly pointing out problems, particularly with management, may feel uncomfortable. The key is to emphasize that these discussions aren’t about criticizing individuals but about improving processes. By focusing on solutions, the atmosphere becomes one of constructive feedback rather than blame. The “why” behind these sessions needs to be clearly explained from the start.

Once we’ve discussed the issues, we assign tasks to be resolved before the next meeting. If a developer struggles with a tool, we’ll make sure they have the resources to get it right. If communication within the team is lacking, we’ll work on new strategies. The important thing is to keep the meetings action-oriented, with clear follow-up on the solutions.

In the beginning, it was tough to convince people to share openly, but now, it’s an essential part of our culture. These meetings provide an opportunity for the team to breathe, to voice concerns, and, most importantly, to take ownership of the problems and their solutions. This simple but effective approach has led to long-term benefits, not only in productivity but also in team morale and cohesion.

So, why do I swear by Kaizen meetings? They keep the momentum going. In a world full of deadlines and constant pressure, it’s easy to lose sight of the bigger picture. These small, regular adjustments keep us aligned, help us solve problems before they become roadblocks, and ensure we’re constantly improving. And let’s face it, a little bit of complaining now and then is the perfect way to stay connected and keep things moving forward.

One unexpected benefit of these meetings is that they help raise awareness and address technical debt over time. By encouraging regular feedback and tackling issues as they arise, we can break down and resolve accumulated tech debt into smaller, more manageable pieces.

As a CTO, I’ve found that Kaizen meetings are the best way to foster true ownership within each team member. When people feel they have a direct impact on the business, product and production process, they start to recognize that everyone faces challenges and that there’s always room to improve. These meetings send a clear message: as a team, we have the power to make our work-life less miserable every week.

What steps are you taking to improve your team’s production process? I’d love to hear your approach.

Originally published at https://dawidmakowski.com on March 9, 2025.

Software development has a way of humbling you.

Early in my career, I was certain about a lot of things-best practices, the “right” way to code, how teams should work. Over time, I realized that many of those “truths” weren’t universal. Some were outright wrong. And some-well, present-me now finds hilarious. The more code I write-and the more late-night debugging sessions I survive-the more I see how few absolutes exist in this field.

Chris Kiehl recently wrote a fantastic blog post reflecting on 10 years in software development, sharing lessons that resonated deeply with me. After 25+ years of hands-on coding, I can say that these lessons become even more true over time. Consider this article my chance to highlight the big mindset shifts that creep in after decades in the trenches-plus a few comedic jabs I wish someone had told me earlier.

Check Chris’ article here: https://chriskiehl.com/article/thoughts-after-10-years

1. Simplicity is a full-time job

Everyone agrees that “good code is simple.” Turns out, keeping it simple takes constant effort. Leave code alone for a month, and it starts sprouting complexities like weeds. If your code is an over-engineered labyrinth, get the lawnmower and trim it down, do it weekly.

2. Complexity isn’t a flex

There was a time I took pride in deciphering arcane systems. Now, I take pride in making them disappear. If your codebase requires a 12-hour onboarding session complete with flowcharts that look like cryptic treasure maps, you haven’t built something genius; you’ve built something that keeps new hires up at night.

3. Typed languages aren’t a luxury-they’re essential

Once, I thought dynamic typing was freedom: no constraints, just vibes. Then came 3 AM bug hunts caused by a single mis-typed variable that turned everything into confetti.

Types aren’t a cage; they’re the guardrails that keep a drowsy driver from veering off a cliff. Especially on teams with varying skill levels, type systems are a lifeline. Spend time up front clarifying function inputs and outputs, and you’ll avoid rummaging through logs at ungodly hours. Especially when you keep hearing from all sides the ever-green: “our customer does not allow us extra time for unit tests…”.

4. Java is actually great… because it’s boring

Any language that just works, has stable tooling, and doesn’t feel compelled to reinvent itself every six months is an asset, not a relic.

Give me “boring and reliable” over “exciting and unpredictable” if we’re running a business. Java, C#, Go-even PHP-prove that reliability can generate real value. Not everything has to be the new shiny toy. In production environments, stability > hype every time.

5. Most programming happens before you write a single line of code

Real engineering happens before you crack open your IDE:

• Understanding the actual problem
• Scoping the requirements and data models.
• Designing a clean, maintainable solution
• Analysing how new changes impact 3rd party integrations
• Listing out all the edge cases, etc.
• Drafting a minimal PRD that later will evolve into an actual documentation

Sitting down to code is the last step. Junior devs often jump straight into coding, only to discover midway that they misunderstood the spec. If you plan like a pro, you can code like one, too. One of my team’s favourite proverbs used to be “ one week of coding can save you 2 hours of planning “.

6. Frontend development is a Kafkaesque nightmare

I used to love frontend. Over the years, it became more like stepping into a haunted mansion where the floor plan changes daily.

New frameworks, shifting best practices, impossible state management battles-some folks thrive on that adrenaline. I realized I like my sanity intact. If you’re a frontend whiz, hats off to you, but keep an eye on that floor. It might vanish tomorrow.

7. ORMs are not the magic solution. Just write the SQL. (But also… use the right tool.)

ORMs seem like a time-saver-until they produce a query so monstrous it stops your database in its tracks. Yes, SQL is an old language, but it’s powerful for a reason. Learn it, use it, and you’ll avoid half the performance nightmares that come with one-size-fits-all abstractions.

Still, it’s not a black-and-white debate:

• Small-to-mid projects? ActiveRecord-style ORMs are fine.
• Large-scale apps? Query builders & raw SQL are your friend.
• Reporting or analytics? ORMs usually create queries that could put your DB on life support.

The key is knowing the right tool for each scenario.

8. Good management is invaluable

Bad management is far too common in this industry. But a truly good manager? That can mean the difference between a thriving team and an early burnout.

A great manager removes roadblocks, fights off scope creep, and helps you grow instead of piling on tasks with no guidance. It’s not just about being technically sharp; it’s about emotional intelligence and shielding your team from chaos.

The main responsibility of a tech manager is to keep everyone, especially top management, grounded in reality.

9. The query planner is a cruel mistress

You may think you know how your database works-until you look at an execution plan that betrays all your assumptions. Indexes are fantastic until they aren’t. Queries are blazing fast until they’re not.

Database tuning is an art form, best approached with patience, a willingness to read logs, and possibly a stiff drink. Or three.

10. Code quality matters more than speed. (Not always.)

Early in my career, I obsessed over writing “beautiful” code. But in a real-world environment, deadlines, business demands, and trade-offs run the show.

Sometimes, shipping on time is more important than achieving conceptual purity. There’s no point polishing code that never makes it into production. The trick is knowing when to make compromises and how to keep track of the debt you’ll inevitably have to pay back.

11. Green tests don’t mean working software

100% test coverage can be a false sense of security. I’ve seen entire test suites pass while the real application burned quietly in the corner.

Tests are only as good as the scenarios you write. A passing test suite that never checks critical business logic is a glorified thumbs-up. Always aim for the right tests, not just a high coverage number. At a minimum, test the real integration points-especially with third-party systems.

12. Git history should be useful, not perfect

When I started, I wanted a Git history that looked like a curated museum exhibit. Then reality (and a few weekend crunch sessions) happened.

The truth is, clarity beats aesthetics. Over-rebasing can wipe out the breadcrumb trail that helps you debug. A perfectly linear commit tree won’t matter if it takes you hours to figure out where a breaking change originated.

Keep it readable, keep it useful-leave the perfectionism at the door. GitFlow is great, but make sure you’re team is big enough to actually need it. Smaller teams usually need a dedicated “mini-gitflow” version of the process.

13. “Best practices” are usually just “best practices for someone else”

Younger devs sometimes assume that best practices are holy commandments. Those with a few more battles under their belts know that “best” depends on your team’s skill set, your business constraints, and your performance or scaling needs.

In other words, Google’s best practice might not help your three-person startup. Context rules everything.

14. Scaling is a problem you wish you had

I used to over-engineer everything, anxiously anticipating the moment a thousand new users would crash my app. Turns out, most projects never see that kind of user load.

If you don’t have an actual scaling challenge yet, don’t spend your life building a fancy architecture for a party that might never happen. Get customers first, and then scale when you actually need to. Otherwise, you’re just building a castle in the sky.

15. “Rewrite it from scratch” is almost always a bad idea

Sure, rewriting your entire codebase sounds refreshing. But the reality is you’ll reintroduce old bugs, lose hidden fixes, and burn countless hours rewriting what already (sort of) works. Meanwhile, your boss wonders why features aren’t being delivered.

Refactor where you can, rewrite only if you must. “Burn it all down” often looks good on paper, but it’s typically a development time sinkhole.

P.S. This does not apply to abandoned legacy codebases, typically built on prehistoric dependencies, libraries, and frameworks-or the complete lack thereof.

16. Microservices aren’t the answer

Ah, microservices: the darling of modern architecture. Also the cause of many a meltdown when you realize how much overhead they introduce.

If you’re not operating at Google-scale, you probably don’t need a microservices labyrinth. A monolith is almost always cheaper, simpler, and easier to maintain. Don’t adopt microservices just because it’s the trendy thing to do. Build a monolith first, then start modularizing it after a year after the first production deployment.

17. You don’t need the “latest and greatest” tools

Chasing trends can be like sprinting on a hamster wheel.

• React or Vue? Doesn’t matter if your product is still stuck in planning.
• Rust or Go? Doesn’t matter if you can’t hire or train developers for them or if your boss/customer doesn’t provide you with a higher budget for this kind of positions.
• Kubernetes? You do not need that complexity unless you’re orchestrating dozens of services.

Pick tools that help you ship now and that your team can realistically manage. The goal is to solve problems, not to collect badges.

18. You don’t need a CS degree to be a great developer

A CS degree is helpful, sure. But it’s not a prerequisite for excellence. Many fantastic devs have non-traditional backgrounds, taught themselves online, or switched careers from something completely different.

That said, you should still learn fundamental algorithms, data structures, and system design. If you skip formal education, make sure you fill in those gaps.

19. Writing good documentation is a superpower

Poor documentation can make even the best code borderline useless. The ability to write clear, helpful docs sets you apart-seriously.

When new developers (or future-you) come on board, well-structured docs can save them days of frustration. If you want job security, become the one who writes (and updates) docs that people can actually follow.

20. Most dev jobs are about glue code, not groundbreaking innovation

We all dream of building the next big thing, but most dev gigs involve hooking up APIs, gluing together libraries, or debugging library conflicts. That’s not a bad thing-it’s just reality.

A lot of software engineering is about problem-solving within constraints, not rewriting the rules of computing. Embrace the “glue code” aspect, because it’s what keeps the wheels turning.

21. Your biggest productivity boost isn’t a new framework-it’s focus

You can pick React, Vue, Svelte, or a random library you found on Reddit. If you’re getting pinged by Slack messages every five minutes, your productivity is still going down the drain.

Focus is the true superpower. Deep work, minimizing interruptions, small hacks like noise-cancelling headphones and focusing on real output over busywork will improve your dev speed more than any fancy new tech.

22. You will never fully catch up with everything. And that’s okay.

It’s tempting to try to know every new JavaScript framework or every new Docker-like tool. But there’s simply too much out there. Once you accept that, you can focus on learning the fundamentals and the big-picture concepts that apply across technologies.

Being able to adapt quickly to new tools and understanding the fundamentals is far more valuable than memorizing every corner of the ecosystem.

23. Seniority isn’t about knowing more-it’s about making better trade-offs

A senior developer isn’t someone who can recite every array method in 15 languages; it’s the person who knows which problems are worth solving.

Senior devs say no to unnecessary features, push back on unrealistic deadlines, and avoid overengineering. They’re the ones who understand the cost of adding complexity-and they’re comfortable advocating simpler solutions.

It’s about making the right trade-offs and knowing which problems are worth solving.

24. Debugging is a skill. Logging is an art.

Yes, debugging means hunting down the cause of a bug. But experienced devs know that proper logging can prevent a hunt in the first place.

• A single well-placed log statement can save you hours of guesswork.
• Log the right things (not just everything).
• Use structured logs, not random print statements.
• Make logs actionable-timestamps, correlation IDs, and useful context.
• Learn to use tools that process and search through logs fast

If your log files read like a jumbled mess, you’re making life harder for yourself (and your teammates). Logging is an area that is most often completely overlooked by developers and considered the least important, rather than being treated as one of the key elements in improving software quality.

25. Senior devs make the team better, not just themselves

Early in your career, you might think a “senior” is the one who solo-crushes every difficult task. But real seniority is about enabling the entire team to thrive.

• Your job is to unblock others, not just yourself.
• Hoarding knowledge makes you a bottleneck, not a genius.
• Mentorship is crucial-if your team isn’t growing, you’re failing.

A senior dev who invests in mentorship, documentation, and automation elevates the whole group.

And in 10 years? I’ll probably look back at this post and laugh at today-me, too. That’s the job-constant change, constant growth, and a dash of self-deprecation.

What’s your biggest dev mindset shift? Let me know below. I’d love to see how your perspective has evolved over time.

Originally published at https://dawidmakowski.com on February 12, 2025.

Dec 7, 2024

When it comes to workflow automation, integrating AI into your business can feel like deciding whether to climb a mountain or take the gondola. Sure, both get you to the top, but one is infinitely easier and less sweaty. In the world of AI-driven automation, the gondola is SharpAPI-the streamlined solution that helps you implement workflow automations faster and more effectively than wrestling with a Large Language Model (LLM) API directly. Let’s break down why SharpAPI is the smarter, more efficient choice for your automation needs.

1. SharpAPI Brings AI to Real-World Workflows

When you work directly with an LLM API like OpenAI’s GPT-4, it’s like being handed a box of unassembled LEGO pieces and being told, “Good luck building a spaceship.” Sure, the potential is there, but you need to design, structure, and refine everything yourself.

SharpAPI, on the other hand, offers industry-specific workflows right out of the box. It’s preconfigured to handle:

• E-commerce needs: Automate product categorization, generate descriptions, and translate listings.
• HR workflows: Parse resumes, create job descriptions, and analyze candidate data.
• Content automation: Summarize articles, paraphrase text, and analyze reviews.
• Marketing solutions: Build SEO-friendly content, craft email campaigns, and generate multilingual content.

With SharpAPI, there’s no need to reinvent the wheel. These workflows are ready to go, saving you time and effort.

2. No Fine-Tuning Headaches

LLM APIs are incredibly powerful but notoriously generic. To get them to perform a specific task, you need to fine-tune prompts or models-a time-consuming process that requires expertise, trial-and-error, and sometimes a bit of luck. Directly integrating with an LLM API often requires in-depth knowledge of AI. You’ll spend time crafting prompts, managing model parameters, and debugging inconsistent outputs. SharpAPI eliminates that guesswork by providing predefined endpoints designed for specific tasks. These endpoints deliver consistent, reliable results without requiring you to become an AI whisperer.

For example:

• Need a product categorized into specific categories? SharpAPI’s categorization API gets it right without lengthy prompt engineering.
• Want to summarize a review? SharpAPI delivers clear, concise results-no additional training or tweaking needed.

3. SharpAPI Saves You Time and Development Effort

Integrating a raw LLM API into your application often means building custom workflows, managing input/output structures, and handling edge cases yourself. With SharpAPI, those workflows are already built and battle-tested.

SharpAPI provides:

• SDKs and tools: SharpAPI provides plug-and-play SDKs for multiple languages and tech stacks, including PHP, Laravel, Python, JavaScript, and .NET. This means developers can integrate the API into their systems in hours-not weeks.
• Standardized outputs: Each API delivers consistent formats, saving you from the frustration of normalizing raw LLM outputs yourself.
• Extensive documentation: Clear guides and examples to help developers get started quickly.
• API monitoring tools: Easily track job history, rerun failed jobs, and manage quotas directly from the SharpAPI dashboard.
• Dedicated support: Whether through forums, email, or chat, SharpAPI’s team is there to help.

In short, SharpAPI does the heavy lifting so your team can focus on building features instead of troubleshooting AI pipelines. It takes just a few minutes to seamlessly integrate SharpAPI’s workflows into your existing software.

4. Compliance? Covered.

Handling sensitive data in today’s world means walking a tightrope of regulations and security concerns. With SharpAPI’s data handling and compliance framework, you can automate workflows without second-guessing your setup:

• GDPR compliance ensures all personal data is processed securely.
• Policies align with global standards, so your app stays ahead of regulatory challenges.
• End-to-end encryption keeps your data safe and sound.

This isn’t just a checkbox for SharpAPI-it’s a fundamental part of how the platform operates. No more scrambling to build a compliance setup from scratch, as you might with an LLM API. More on this topic in Data Handling and Compliance article.

5. Self-Improving Workflows

SharpAPI isn’t static-it’s always learning and improving. Once integrated, the platform optimizes workflows and updates itself with improved models and data handling without requiring your intervention.

This “set it and forget it” approach means your workflows keep getting smarter over time, so you can focus on scaling your business instead of maintaining your automation tools.

While SharpAPI does use powerful models like OpenAI’s GPT-4, it doesn’t stop there. The platform actively tests and integrates new AI models like Sonnet and Gemini to ensure the best results for specific tasks. It’s not just a “use-this-one-model” solution-it’s a dynamic, evolving platform designed to stay ahead of the curve.

6. Scalable and Tested for Growth

SharpAPI is built to grow with you. Whether you’re running a lean startup or managing an enterprise-level operation, the platform scales seamlessly.

It is designed for real-world use cases, with scalability built-in:

• Predefined rate limits: SharpAPI ensures fair usage without unpredictable throttling.
• High-performance infrastructure: Its backend is optimized to handle enterprise-level demands without downtime or lag.
• Available also via a wide range of API Marketplace with their unified integration capabilities.

What Makes SharpAPI Better Than LLM APIs Directly?

Here’s the short version:

• Purpose-built workflows: SharpAPI takes LLM capabilities and refines them for specific tasks.
• Faster integration: No need for extensive fine-tuning or setup-just plug and play.
• Compliance out of the box: Handle sensitive data confidently with pre-built security and regulatory safeguards.
• Developer-friendly tools: Easy APIs, comprehensive SDKs, and helpful documentation.
• Smarter over time: Workflows improve automatically as models are updated.
• Focus on scalability: Built to handle projects of any size with minimal effort.

SharpAPI: Automating Workflows Without the Hassle

Here’s the bottom line: integrating an LLM API directly can feel like navigating uncharted waters without a map-possible, but unnecessarily complicated. SharpAPI takes the raw power of AI models and refines it into polished, industry-ready workflows, offering a faster, easier, and more cost-effective solution.

Instead of spending time building and fine-tuning workflows from scratch, SharpAPI hands you ready-to-use tools tailored to your needs, whether you’re running an e-commerce site, automating HR tasks, or managing global content. It’s the well-charted route, guiding you smoothly to your destination while saving you from the headaches, wasted time, and unnecessary costs of a DIY approach.

By choosing SharpAPI, you’re empowering your team to focus on innovation rather than implementation. Let SharpAPI handle the heavy lifting-your workflows, your efficiency, and your sanity will thank you.

Originally published at https://sharpapi.com.

Alright, imagine this: you’ve got a Laravel Nova dashboard, a list of content fields in multiple languages, and a burning desire to automate translations because, let’s be real, manually doing it is not exactly a great time.

Enter the SharpAPI AI Translator for Laravel Nova. This package seamlessly plugs AI-powered translation directly into your Nova dashboard, eliminating repetitive translation tasks and freeing you up to focus on the good stuff.

Want to see all the package details? Head over to GitHub: https://github.com/sharpapi/nova-ai-translator

What Exactly Does This Package Do?

In a nutshell, it combines the Spatie’s laravel-translatable package with the superpowers of SharpAPI’s AI, transforming those content fields in your app into effortlessly translatable assets. The result? A new action on your Nova dashboard called 🤖 Initiate AI Translation that takes care of the translation work for you.

From the Nova resources list or the edit screen, you can queue up translations between any configured languages directly in Nova, with the AI taking over as soon as you hit the button. Need to translate a blog post from English to Spanish? It’s handled.

Who’s This For?

If you’re a Laravel Nova user managing content in multiple languages, this package is for you. It’s ideal for teams that regularly work with internationalized apps and need content quickly translated without manually flipping through Google Translate. Imagine all that time saved when your content auto-magically translates itself right from Nova!

Setting Up the SharpAPI AI Translator

Requirements

Make sure you’re running:

• Laravel: ^9.0+
• Laravel Nova: 4.0+
• PHP: 8.0+
• And have spatie/laravel-translatable installed

You’ll also need an account at SharpAPI.com for API access, but we’ll get to that.

Installation

• Install the Package:

composer require sharpapi/nova-ai-translator

• Configure API Access: Add your API key from SharpAPI to your .env:

SHARP_API_KEY=your-sharp-api-key

• Set Up Supported Languages: Define your locales in config/app.php under the locales key:

return [
    'locales' => [
        'en' => 'English',
        'es' => 'Spanish',
        'fr' => 'French',
        // Add any other languages your app needs
    ],
];

• Add to Your Nova Resource Models: Your translatable models should use:
• The HasTranslations trait from Spatie.
• [Highly Recommended] The Actionable and Notifiable traits to track actions.

Here’s a quick setup for, say, a BlogPost model:

namespace App;

use Laravel\Nova\Actions\Actionable;
use Illuminate\Notifications\Notifiable;
use Spatie\Translatable\HasTranslations;

class BlogPost
{
    use Actionable, Notifiable, HasTranslations;

    protected $translatable = ['title', 'subtitle', 'content'];
}

• Integrate the TranslateModel Action: Hook the TranslateModel action into your Nova resource by adding it to the actions array:

use SharpAPI\NovaAiTranslator\Actions\TranslateModel;

public function actions()
{
    return [
        (new TranslateModel())->enabled(),
    ];
}

• Enable Queues: This action uses a queue to handle translations asynchronously, so make sure your queue is ready to go.

Using the TranslateModel Action in Nova

Once integrated, the action lives right in your Nova resource. Here’s how it works:

• Kickstart AI Translation: Open the action either from the resources list or from the edit view of any resource.
• Example: Triggering the Action from the Edit View

• Select Translation Settings: A form lets you pick the source and target languages and even set the tone. You’ll also see a list of fields that will be translated, so there are no surprises.

• Hit Translate and Relax: Once you confirm, the action checks if the target fields are already populated. If they are, it gently suggests that you clear them before proceeding. Assuming all systems are go, it queues the translation job. You can even keep an eye on it if you’re using the Actionable and Notifiable traits.
• Track Progress and Logs: Nova’s action log feature helps track the translations. This is handy if you need to debug any issues or just like seeing AI in action.
• Example: Translation Log in Action

• Example: Error Handling (if it goes sideways)

Tips & Tricks

• Set It and Forget It: This setup lets you queue translations without worrying about timing or load. It’s especially useful for scaling multilingual apps without scaling translation tasks.
• Translation Strategy: Fine-tune how often you trigger translations based on the volume and frequency of content updates.
• Localization Needs?: Since this setup integrates with spatie/laravel-translatable, you get the best of both worlds: structured localization with the muscle of an AI translation.

With SharpAPI AI Translator for Laravel Nova, your app’s translation game just got a massive upgrade with its new Laravel AI capabilities. Give it a spin, and let us know how it works for you!

Originally published at https://sharpapi.com.