Forem: Mohamed Akthar

I Built a Mobile Game Using AI Without Knowing Flutter — Here’s What Happened

Mohamed Akthar — Tue, 21 Apr 2026 12:00:00 +0000

I used to collect ideas but never execute them.

When AI tools got popular, I thought that problem was solved.

It wasn’t.

I still wasn’t building anything.

⚡ The Trigger

A friend showed me Google AI Studio.

For the first time, it felt like I could actually turn an idea into something real.

I love puzzles — Sudoku, Nonogram, anything that makes you think for a while — and I could easily spend hours on them.

So I did something impulsive:

I bought a Google Play Developer account.

Now I had a problem — I had spent money, and I had never shipped anything before.

❌ The First Attempt (Failed)

Naturally, I started with a puzzle app.

Bad idea.

It was too complex. It broke constantly.

Every change created new issues. AI-generated code wasn’t stable enough, and I didn’t have the knowledge to fix things properly.

I almost quit.

🧱 What Went Wrong

Looking back, it was obvious:

I tried to build too much too early
I had no clear design direction
I relied on AI without structuring the work
I underestimated how much iteration real apps need

That failure forced a reset.

🔄 The Pivot

Instead of quitting, I simplified everything.

I started building a reaction time test.

That small decision led to my first shipped app:

ReflexLab

🤖 How I Actually Built It

I don’t know Flutter.

So I used AI like a system:

Claude → broke the app into phases
Gemini → implemented step by step
Me → orchestrated everything

My role wasn’t “coding.”

It was:

deciding what to build
structuring prompts
fixing what broke

⏳ The Real Bottleneck

Not coding.

Limits.

Most of the 2.5 months went into:

hitting token limits
waiting for resets
retrying broken outputs

AI speeds things up… until it doesn’t.

🧠 What I Learned

1. AI doesn’t replace understanding

If something breaks, you still need to reason through it.

2. “Build for free with AI” is a myth

You pay with:

time (limits, retries)
or money (subscriptions)

3. Design matters a lot

Without direction, AI defaults to the same generic dark UI.

4. Building isn’t enough

No ASO → no visibility

No SEO → no traffic

No marketing → no users

🚀 What It Became

ReflexLab started as something even I didn’t enjoy playing.

Now it has:

4 game modes
daily challenges
leaderboards
progress tracking

And I’m still expanding it.

🎯 Final Thought

I still don’t “know” Flutter the traditional way.

But I shipped something real.

That changed everything.

🔗 Links

🌐 Website: roguewavelabs.dev

📱

Try ReflexLab on Google Play

What would you build if you didn’t know the stack?

Why My `@Transactional` Did Absolutely Nothing (A Spring Proxy Trap)

Mohamed Akthar — Thu, 05 Feb 2026 06:16:27 +0000

I Spent Hours Debugging a Concurrency Bug That Should Not Have Existed

Two requests hit my service at the same time.

Both generated the same ID.

No errors. No warnings. Just wrong data.

The fix was literally one line.

Understanding why that fix worked, though, took much longer — and taught me a hard lesson about how @Transactional actually works in Spring.

The Problem

I had a service that generates unique order IDs. Here is the simplified version:

@Service
public class OrderService {

    public Order createOrder(OrderRequest req) {
        // The trap: calling the transactional method internally
        String orderId = generateUniqueId(); 
        // ... create order
    }

    @Transactional
    public String generateUniqueId() {
        var counter = counterRepo.findById("ORDER").orElseThrow();
        counter.increment();
        counterRepo.save(counter);
        return "ORD-" + counter.getValue();
    }
}

Two requests came in at the same time.

Both got the same order ID.

I assumed @Transactional would protect this (ACID, right?). It didn’t.

The Hard Truth

The real issue wasn’t the isolation level or database locking.

The transaction wasn’t even starting.

Spring didn't throw an error. It didn't warn me about a misused annotation. It just silently ignored it and ran the code without a transaction.

Why It Didn’t Work

Spring’s @Transactional (and AOP in general) works using proxies.

When a Spring-managed bean is called from the outside (like from a Controller), you aren't calling the raw object. You are calling a proxy that wraps your object. That proxy is responsible for the "magic"—starting the transaction, committing it, or rolling it back.

Controller → (Spring Proxy) → OrderService
                   ↑
        transaction starts here

But when you call a method from inside the same class, the call never goes through the proxy.

public Order createOrder(OrderRequest req) {
    String orderId = generateUniqueId();  // This is a direct call on 'this'
}

This is self-invocation.

No proxy → No transaction → @Transactional is just a useless decoration here.

The Fix

Option 1: The "Clean" Way (Split the Class)

Move the transactional logic to a dedicated component. This forces the call to go through a fresh proxy.

@Service
public class IdGenerator {

    @Transactional
    public String generateOrderId() {
        var counter = counterRepo.findById("ORDER").orElseThrow();
        counter.increment();
        counterRepo.save(counter);
        return "ORD-" + counter.getValue();
    }
}

@Service
@RequiredArgsConstructor
public class OrderService {

    private final IdGenerator idGenerator;

    public Order createOrder(OrderRequest req) {
        // Now calling an external bean, so the proxy intercepts it!
        String orderId = idGenerator.generateOrderId(); 
        // ...
    }
}

Now the transaction starts correctly. No duplicate IDs. This is the approach I prefer—it respects Single Responsibility Principle.

Option 2: The "Self-Injection" Way (Legacy Code)

If you are stuck in a massive legacy class and can't refactor, you can inject the class into itself.

@Service
public class OrderService {

    @Autowired
    private OrderService self; // Inject the proxy of itself

    public Order createOrder(OrderRequest req) {
        // Call the method on the proxy, not 'this'
        String orderId = self.generateUniqueId(); 
    }

    @Transactional
    public String generateUniqueId() {
        // ...
    }
}

Does it work? Yes.

Does it look weird? Absolutely. Is it a circular dependency waiting to happen? Sometimes. Use with caution.

The Golden Rule

Annotations like @Transactional, @Async, @Cacheable, and @Retryable only work when:

The method is called from outside the class.
The call goes through a Spring-managed proxy.
The method is public (usually).

If you call this.myTransactionalMethod(), you are bypassing Spring entirely.

TL;DR

@Transactional relies on Spring proxies.
Internal method calls (this.method()) skip the proxy.
No proxy = No transaction.
Fix it by extracting the method to a new service or using self-injection.

Ever spent hours debugging something that turned out to be a "basics" issue? Would love to hear your "this should’ve been obvious" bugs in the comments! 👇

3 Spring Boot Mistakes I Made (And How to Fix Them)

Mohamed Akthar — Tue, 27 Jan 2026 11:01:53 +0000

After 2+ years with Spring Boot, these are mistakes I still catch myself making.

1. Missing Input Validation

I've shipped endpoints like this way too many times:

@PostMapping("/register")
public ResponseEntity<?> register(@RequestBody RegisterRequest req) {
    // frontend handles validation anyway right?
    return ResponseEntity.ok(authService.register(req));
}

Then someone sends an empty email. Or a 500 character username. Or just {}. Now there's garbage in the database and I'm spending my evening fixing it.

What I do now:

public class RegisterRequest {
    @NotBlank
    @Size(min = 3, max = 30)
    private String username;

    @Email
    @NotBlank
    private String email;
}

@PostMapping("/register")
public ResponseEntity<?> register(@Valid @RequestBody RegisterRequest req) {
    return ResponseEntity.ok(authService.register(req));
}

Takes minutes. Saves hours.

2. The N+1 Query

Had an endpoint to get transactions with their details:

@GetMapping("/transactions")
public List<TxnResponse> getAll() {
    var txns = txnRepo.findByUserId(userId);
    return txns.stream()
        .map(t -> new TxnResponse(t.getId(), t.getAmount(), t.getDetails())) // oops
        .toList();
}

t.getDetails() fires a query. For each transaction. 100 transactions = 101 queries. Endpoint took 4 seconds.

Fix:

@Query("SELECT t FROM Transaction t JOIN FETCH t.details WHERE t.userId = :userId")
List<Transaction> findByUserIdWithDetails(@Param("userId") Long userId);

Down to 1 query.

Enable spring.jpa.show-sql=true while developing. If you see the same select repeating, you've got N+1.

3. Catching Exception

public AccountDTO getAccount(Long id) {
    try {
        var acc = accountRepo.findById(id).orElseThrow();
        return mapper.toDto(acc);
    } catch (Exception e) {
        log.error("failed to get account", e);
        throw new RuntimeException("something went wrong");
    }
}

"something went wrong" - super helpful when debugging at 11pm.

Was it a db timeout? A null somewhere? A bug I introduced? The log just says "failed to get account" for everything.

What I do now:

public AccountDTO getAccount(Long id) {
    try {
        var acc = accountRepo.findById(id)
            .orElseThrow(() -> new NotFoundException("account not found: " + id));
        return mapper.toDto(acc);
    } catch (DataAccessException e) {
        log.error("db error fetching account {}", id, e);
        throw new ServiceException("database unavailable");
    }
    // let other exceptions bubble up - they're probably bugs
}

Specific exceptions = specific fixes.

tldr

Add @Valid - don't trust input
Check for N+1 - turn on sql logging
Catch specific exceptions - "something went wrong" helps nobody or even better use @ControllerAdvice if possible

Basic stuff but easy to skip when you're rushing.

What mistakes do you keep making? Comment down below

3 Spring Boot Mistakes I Made (And How to Fix Them)

Mohamed Akthar — Tue, 27 Jan 2026 11:01:53 +0000

After 2+ years with Spring Boot, these are mistakes I still catch myself making.

1. Missing Input Validation

I've shipped endpoints like this way too many times:

@PostMapping("/register")
public ResponseEntity<?> register(@RequestBody RegisterRequest req) {
    // frontend handles validation anyway right?
    return ResponseEntity.ok(authService.register(req));
}

Then someone sends an empty email. Or a 500 character username. Or just {}. Now there's garbage in the database and I'm spending my evening fixing it.

What I do now:

public class RegisterRequest {
    @NotBlank
    @Size(min = 3, max = 30)
    private String username;

    @Email
    @NotBlank
    private String email;
}

@PostMapping("/register")
public ResponseEntity<?> register(@Valid @RequestBody RegisterRequest req) {
    return ResponseEntity.ok(authService.register(req));
}

Takes minutes. Saves hours.

2. The N+1 Query

Had an endpoint to get transactions with their details:

@GetMapping("/transactions")
public List<TxnResponse> getAll() {
    var txns = txnRepo.findByUserId(userId);
    return txns.stream()
        .map(t -> new TxnResponse(t.getId(), t.getAmount(), t.getDetails())) // oops
        .toList();
}

t.getDetails() fires a query. For each transaction. 100 transactions = 101 queries. Endpoint took 4 seconds.

Fix:

@Query("SELECT t FROM Transaction t JOIN FETCH t.details WHERE t.userId = :userId")
List<Transaction> findByUserIdWithDetails(@Param("userId") Long userId);

Down to 1 query.

Enable spring.jpa.show-sql=true while developing. If you see the same select repeating, you've got N+1.

3. Catching Exception

public AccountDTO getAccount(Long id) {
    try {
        var acc = accountRepo.findById(id).orElseThrow();
        return mapper.toDto(acc);
    } catch (Exception e) {
        log.error("failed to get account", e);
        throw new RuntimeException("something went wrong");
    }
}

"something went wrong" - super helpful when debugging at 11pm.

Was it a db timeout? A null somewhere? A bug I introduced? The log just says "failed to get account" for everything.

What I do now:

public AccountDTO getAccount(Long id) {
    try {
        var acc = accountRepo.findById(id)
            .orElseThrow(() -> new NotFoundException("account not found: " + id));
        return mapper.toDto(acc);
    } catch (DataAccessException e) {
        log.error("db error fetching account {}", id, e);
        throw new ServiceException("database unavailable");
    }
    // let other exceptions bubble up - they're probably bugs
}

Specific exceptions = specific fixes.

tldr

Add @Valid - don't trust input
Check for N+1 - turn on sql logging
Catch specific exceptions - "something went wrong" helps nobody or even better use @ControllerAdvice if possible

Basic stuff but easy to skip when you're rushing.

What mistakes do you keep making? Comment down below