DEV Community: RockAndNull

The danger of the "ok" project

RockAndNull — Tue, 31 Mar 2026 12:48:11 +0000

The hardest part of building a project isn’t always dealing with failure.

It’s dealing with a project that is doing just well enough to keep going. There is a common situation in software where a project isn’t a total disaster, but it isn’t a hit either.

It has some users and some traction, but not enough to be a clear success. This is the "middle ground," and as Dropbox founder Drew Houston once noted, it can be the most difficult place to be. If a project fails, the choice to stop is easy. If it’s a success, the choice to grow is easy. But when it’s just "okay," it stays alive and uses up energy without a certain future.

In the AI era, the timing of this decision feels different because the industry moves so fast. A few years ago, it was common to let a project sit for a long time to see if it would eventually grow. Today, a project that is only "okay" now might be outdated in a very short time because tools and markets change every month. The "wait and see" approach carries a new kind of risk. The speed of the field makes the gap between a slow-growing project and a fast-moving market much more obvious.

Deciding what to do next usually involves a mix of data and intuition.

Some look at retention data to see if users are actually staying. It is a choice between waiting for more growth or deciding that the current traction isn't enough to justify more time. In a world that moves this fast, the middle point remains a challenging spot to navigate, with no clear data-driven/rational solution.

Who is going to train the juniors?

RockAndNull — Thu, 05 Feb 2026 09:59:43 +0000

Not long ago, junior engineers learned by working closely with more senior ones.

Code reviews, design discussions, and mistakes created friction, and that friction built understanding.

AI changed that.

Today, answers are instant. Code is generated. Progress looks fast, but depth is optional. A junior can ship without ever fully understanding why something works. That’s powerful, and risky.

During our last internship season, our intern chose not to use AI tools while coding. Short-term productivity suffered. Tasks took longer.

But something more important happened: they struggled, debugged, and built intuition. When they would introduce AI tools, the effect would be dramatic. With experience in place, AI will become a multiplier instead of a shortcut. That’s the real distinction.

AI is great at accelerating experienced engineers. It’s bad at replacing the process that creates them. If we remove friction too early, we don’t get better engineers, just faster output with hidden gaps. And those gaps surface later, when systems scale or fail.

This isn’t about banning AI. It’s about being intentional. Let juniors struggle a bit. Accept short-term productivity loss.

Otherwise, we’re not training the next generation of engineers; we’re just shipping code faster.

How We Fixed SQLite Database Locks in Spring Boot (And Got a 5x Performance Boost)

RockAndNull — Fri, 30 Jan 2026 10:36:55 +0000

We recently ran into a frustrating production issue: our Spring Boot application using SQLite would occasionally lock up, and the only way to recover was to restart the entire service. After some investigation and configuration changes, we not only fixed the locking issue but also saw dramatic performance improvements. Here's what we learned.

The Problem

Our production SQLite database would intermittently enter a locked state, causing requests to hang and eventually fail. The database would remain locked until we performed a manual restart; not exactly the kind of reliability we wanted in production.

The Root Cause

SQLite is designed differently from traditional client-server databases like PostgreSQL or MySQL. It's a file-based database that works best with single-connection access. However, Spring Boot's default connection pooling configuration doesn't account for SQLite's unique requirements, leading to connection conflicts and database locks.

The Solution

We made several targeted configuration changes to our application.properties to optimize Spring Boot for SQLite:

1. Single Connection Pool

spring.datasource.hikari.maximum-pool-size=1
spring.datasource.hikari.minimum-idle=0

SQLite performs best with a single connection. Multiple connections can lead to locking issues, so we configured HikariCP to maintain just one connection at a time.

2. Aggressive Connection Management

spring.datasource.hikari.connection-timeout=10000
spring.datasource.hikari.idle-timeout=10000
spring.datasource.hikari.max-lifetime=30000

These settings ensure connections don't linger unnecessarily, reducing the chance of locks.

3. Leak Detection

spring.datasource.hikari.leak-detection-threshold=5000

This helps us spot any connections that are held longer than expected, making debugging much easier.

4. Disable Open-in-View

spring.jpa.open-in-view=false

This was crucial. By default, Spring Boot keeps JPA connections open for the entire HTTP request lifecycle. We disabled this to ensure connections are released as soon as the database operation completes.

5. Manual Transaction Control

spring.datasource.hikari.auto-commit=false

Disabling auto-commit gives us explicit control over transactions, preventing unexpected commits that could cause locking issues.

The Results

The improvements were dramatic. We load-tested our API using k6 with identical test parameters:

Before the changes:

Total requests in 5 minutes: 1,736
Success rate: 76%
Failed requests: 411

After the changes:

Total requests in 5 minutes: 11,381
Success rate: 99%
Failed requests: 1

That's a 6.5x increase in throughput and virtually eliminated failures. More importantly, we haven't seen a single database lock since deploying these changes.

Key Takeaways

SQLite isn't PostgreSQL - Default Spring Boot configurations are optimized for client-server databases, not file-based ones.
Single connection is key - SQLite's architecture works best with one connection at a time.
Disable open-in-view - This JPA pattern is convenient but problematic with SQLite.
Monitor your connections - Leak detection helped us identify issues during development.

If you're using SQLite with Spring Boot, these configurations can save you from production headaches and give you some nice performance wins along the way.

Cog in a great machine VS building one from scratch

RockAndNull — Thu, 22 Jan 2026 15:41:08 +0000

Having spent time as a software engineer in a large tech company and later launching my own company, I’m often asked which experience is “better.”

The honest answer is: they’re both exciting, deeply fulfilling in different ways, and not really comparable.

Being a software engineer in a big company

Working in a big company feels like being a cog in an incredible, well-oiled machine. And I don’t mean “cog” in a negative way.

The machine is complex, powerful, and built by thousands of highly skilled people. Your role is clearly defined. You are expected to go deep, specialize, and deliver excellence within your scope. When something breaks, there’s a process:

You identify the issue
You report it
It moves through product managers, designers, tech leads, and prioritization cycles

Your responsibility often ends at reporting clearly and correctly. Someone else owns the decision, someone else owns the fix, and that’s by design. This separation of concerns is what allows large organizations to scale.

Something is reassuring about this. You can focus on engineering problems, grow technically, and learn from incredibly talented peers. The impact is massive, even if it’s sometimes indirect.

Launching your own company

Starting your own company feels very different.

Instead of being a cog in a large machine, you’re building a much smaller machine from scratch. And at the beginning, you are most of the parts.

The boundaries between roles are blurry or nonexistent. You might notice a product issue, report it to yourself, prioritize it, design the solution, implement it, deploy it, and then answer the support ticket that comes in afterward.

There’s no “this isn’t my job.”

Even if your official role is “software engineer” or “founder,” reality doesn’t care. If something needs fixing and you’re the best person to do it, then that’s what you’ll do.

This can be exhausting, but it’s also incredibly energizing. You see the full lifecycle of decisions. You feel the consequences immediately. The feedback loop is short and very real.

Two exciting, very different journeys

What I’ve learned is that these two worlds shouldn’t be compared as better or worse.

They’re simply different journeys:

Big companies teach you scale, rigor, and depth
Startups teach you ownership, adaptability, and breadth

One is about mastering your part of the system.

The other is about making sure the system works at all.

Both are exciting. Both are challenging. And both shape you in ways that stay with you.

The important thing isn’t choosing the “right” path, but understanding what kind of journey you’re on, and why you chose it.

Introducing Pale Blue Spring Admin: auto-generated admin UI for Spring Boot

RockAndNull — Fri, 14 Nov 2025 09:54:40 +0000

At Pale Blue, we’ve always admired the magic of Django Admin - that moment when you define your models and instantly get a clean, intuitive interface to browse, search, and manage your data. When we transitioned our backend stack to Spring Boot , we missed that simplicity — the ability to see and interact with our data models without writing extra code or wiring up a custom UI.

So… we built it.

We’re excited to announce the release of our second open-source library: pale-blue-spring-admin

What It Does

Pale Blue Spring Admin brings an auto-generated admin interface to your Spring Boot applications - inspired by Django’s admin, but built for the Spring + Kotlin ecosystem.

Once you install the library, it auto-discovers your JPA entities and exposes them through an intuitive web interface. From there, you can:

Browse all entities in your database
View records with pagination, search, and basic sorting
Navigate relationships through linked foreign keys

Currently, the interface is read-only , but we’re already working on write operations (create, update, delete) for a future release.

Designed with simplicity in mind

One of our core goals was simplicity. We wanted developers to drop the library into their Spring Boot project, define their JPA entities as usual, and immediately get a clean, intuitive interface - no boilerplate, no manual wiring, no custom views to maintain. The admin UI is intentionally minimal, predictable, and easy to navigate, making data exploration effortless even in large projects.

Access to the admin interface must be explicitly defined, giving you full control over who can reach it and how they authenticate. In our documentation, we also provide a recommended lightweight authentication setup to help teams secure the admin area quickly, while still allowing more advanced configurations if needed.

Built in Kotlin. For Kotlin.

This project is also a milestone for us - our first backend library written entirely in Kotlin , marking our ongoing shift to Kotlin for backend development. We love the clarity and expressiveness Kotlin brings to Spring Boot projects, and we’re excited to contribute something useful back to the Kotlin and Spring communities.

Get Started

The library is open-source and available now: github.com/PaleBlueApps/pale-blue-spring-admin

We’d love your feedback, contributions, and ideas on how to make it even better.

The rewrite dilemma in software engineering

RockAndNull — Thu, 06 Nov 2025 12:10:38 +0000

Rewriting software is a topic that sparks endless debates among engineers. The first reaction when joining an existing project is often: “This is a mess, let’s start fresh”. It’s tempting to imagine a perfect, clean system - elegant architecture, fewer compromises, faster development.

Sometimes a rewrite is justified. But what’s often overlooked are the small fixes, edge case patches, and tweaks accumulated over time. That “messy” system is often stable because of these hard-earned adjustments.

A rewrite might feel faster initially, but regaining that stability - rediscovering subtle fixes, handling edge cases, and testing thoroughly - often takes longer than improving the existing code.

The key is balance. Rewrites aren’t inherently bad, but they come with hidden costs. Stability, accumulated fixes, and historical knowledge are valuable, and any rewrite should account for them before lighting the match.

Don’t chase perfection blindly - sometimes improving what works is smarter than starting over.

Happy coding!

T-Shaped engineers: the blueprint for building with AI

RockAndNull — Thu, 23 Oct 2025 14:11:21 +0000

The concept of the T-shaped engineer isn't new. It's been around, quietly championed by forward-thinking tech leaders and organizations. But in 2025, as LLMs transform how we build software, this professional archetype has evolved from "nice to have" to essential.

What Makes an Engineer T-Shaped?

Picture the letter T. The horizontal bar represents breadth - a working knowledge across a wide range of technologies, methodologies, and domains. The vertical stem represents depth - expert-level mastery in one or a few specific areas.

A T-shaped engineer might have deep expertise in distributed systems architecture while maintaining conversational fluency in frontend frameworks, DevOps practices, data engineering, and security principles. They can collaborate meaningfully with specialists across disciplines because they understand the fundamentals, even if they're not experts in everything.

The AI Amplification Effect

Here's where the AI era changes everything.

With LLMs, both general SOTA models and countless domain-specific models, the barrier to working across multiple technologies has dropped dramatically. An engineer with fundamental understanding can now leverage AI to scaffold applications in languages they haven't touched in years, generate infrastructure-as-code configurations, or even implement features in unfamiliar frameworks.

The breadth of the T becomes supercharged. That conversational knowledge of various domains? It's now enough to effectively direct AI tools to produce working solutions across technologies you don't use daily.

But here's the critical insight: AI is a powerful accelerator, but it's not infallible.

Depth as the Safety Net

This is where the depth of the T becomes your organization's safety net and quality standard.

In your areas of deep expertise, you can catch AI hallucinations and incorrect implementations before they reach production, guide AI tools toward best practices that go beyond surface-level correctness, make architectural decisions that AI can't reliably make on its own, identify security vulnerabilities or performance issues that AI-generated code might introduce, and maintain high standards even when moving fast with AI assistance.

Think of it this way: AI gives you the ability to paint across a massive canvas. Your depth expertise ensures that the critical parts of that painting are museum-quality.

Growing T-Shaped Engineers

Becoming T-shaped isn't about forcing engineers to master everything. It's about recognizing and developing depth in areas where engineers show natural aptitude and interest, encouraging curiosity across domains without demanding mastery, creating opportunities for meaningful exposure to different parts of the stack, and celebrating both deep expertise and collaborative breadth.

The engineers who will define the next decade aren't those who can do everything or those who know only one thing. They're the ones who can go deep where it matters and go wide where AI can help - combining human expertise with artificial intelligence to build better software, faster and more safely than either could alone.

The T-shaped engineer isn't just relevant in the AI era. It's the blueprint for how exceptional engineers will work.

Automatic resource cleanup in Jetpack ViewModels using AutoCloseable

RockAndNull — Tue, 07 Oct 2025 09:15:15 +0000

When building Android applications with Jetpack ViewModels, proper resource management is crucial to prevent memory leaks and ensure efficient cleanup of services. In this post, we’ll explore an elegant pattern that leverages Kotlin’s AutoCloseable interface to clean up resources when a ViewModel is destroyed automatically.

The Problem

Traditionally, when a ViewModel needs to clean up resources, we override the onCleared() method:

class MyViewModel(private val itemsService: ItemsService) : ViewModel() {

    override fun onCleared() {
        super.onCleared()
        itemsService.cleanup()
    }
}

While this works, it requires boilerplate code for each service that needs cleanup.

AutoCloseable Pattern

Android’s ViewModel class supports automatic resource cleanup through the AutoCloseable interface. When a ViewModel is cleared, any services that implement AutoCloseable and are passed to the ViewModel constructor will automatically have their close() method invoked.

Implementing AutoCloseable Services

First, make your service implement AutoCloseable:

interface ItemsService : AutoCloseable {
    val items: Flow<List<Item>>
    suspend fun getItems(): List<Item>
    // ... other methods
}

Then implement the close() method:

class RealItemsService : ItemsService {
    private val scope = CoroutineScope(SupervisorJob() + Dispatchers.Default)

    [....]

    override fun close() {
        scope.cancel()
        println("ItemsService closed - resources cleaned up")
    }
}

Passing AutoCloseable Services to a ViewModel

Here’s the key: you can directly pass all your AutoCloseable services to the ViewModel constructor, and let the framework handle cleanup automatically.

class HomeViewModel(
    private val itemsService: ItemsService,
    private val customersService: CustomersService,
    private val invoiceService: InvoiceService
) : ViewModel(
    itemsService,
    customersService,
    invoiceService
) {

    [....]    
}

When HomeViewModel is cleared, the Android framework automatically calls close() on each of these services — no need to override onCleared() or introduce a custom BaseViewModel.

Conclusion

The AutoCloseable pattern in ViewModels provides an elegant solution for automatic resource management. By implementing AutoCloseable on your services and passing them to the ViewModel constructor, you ensure proper cleanup without writing repetitive boilerplate code. This approach leads to cleaner, more maintainable code while preventing memory leaks and ensuring resources are released appropriately.

Happy coding!

Billin: Building a modern cross-platform invoice app with Compose Multiplatform

RockAndNull — Mon, 22 Sep 2025 13:30:53 +0000

When we set out to build Billin - our smart invoice maker for freelancers, small businesses, and professionals - we knew we wanted to deliver a clean, reliable experience that helps people create, send, and track professional invoices in seconds.

On Android, this was straightforward: Kotlin and Jetpack Compose gave us the productivity we needed, and our users loved the fast, polished results. But we didn’t want to stop there. Freelancers and small businesses often work across devices and ecosystems, and many of them asked for an iOS version. That’s where Compose Multiplatform (CMP) came into play.

Why Compose Multiplatform?

With Billin, users can preview invoices as PDFs, track payments, manage clients, and manage their services inventory - all from their phone. To bring this experience to iOS, we had two choices:

Build a completely separate SwiftUI app.
Leverage the tools we already loved (Kotlin + Compose) and extend them to iOS.

We chose option two - and Compose Multiplatform (CMP) proved to be the right call.

Challenges and solutions

Migrating from Android-first to CMP came with a few bumps. For example:

On Android, we relied on the AndroidX PDF Preview component to display invoices. On iOS, this wasn’t available. Our solution was to generate image previews of invoices, which worked flawlessly across both platforms.
Some UI conventions simply didn’t translate well. We disabled ripple effects on iOS and replaced certain screen transitions with animations that feel more at home in the Apple ecosystem.
We carefully reworked layouts and spacing so that iOS users wouldn’t feel like they were using a “ported” Android app.

The good news? Most of the Jetpack Compose libraries we were already using had multiplatform support. And with our own open-source library, pale-blue-kmp-core, we had a big head start in sharing logic across platforms.

The architecture behind Billin

Billin is built on a service-based architecture , which has been key in making multiplatform development efficient. Here’s how:

We use a SystemService layer to abstract system-level interactions (like file storage or sharing).
With Kotlin’s expect/actual mechanism, we implement platform-specific code while keeping most of the logic shared.
Our monorepo pattern allows us to share models, business logic, and even some backend code between Android, iOS, and our server.

Speaking of the server, our backend is also written in Kotlin (Spring). That means Billin isn’t just multiplatform on mobile - it’s part of a unified Kotlin ecosystem that runs across frontend, backend, and shared libraries.

Delivering a cross-platform design that feels right

For Billin, we made a deliberate design choice: the app should look clean and modern , but not be tightly coupled to either Android’s Material Design or iOS’s Human Interface Guidelines. Instead, we aimed for a neutral yet elegant visual style that feels familiar on both platforms.

That said, we didn’t ignore platform conventions. We still rely on native UI elements and animations where they make sense—for example, transitions on iOS behave like iOS users expect, and system dialogs follow platform guidelines. By combining a shared, platform-agnostic design language with native touches, Billin feels consistent and professional while still feeling at home on whichever device you’re using.

Simplifying In-App Purchases with RevenueCat

One area where we were particularly impressed was in-app purchases. Setting up IAPs in the Play Console and App Store Connect is still required, but managing them across both platforms can be a real pain - keeping product IDs consistent, making sure pricing aligns, and then wiring everything up in the client. RevenueCat solved much of that complexity by providing a dynamic, configurable paywall that pulls in the right products at runtime.

This not only meant we didn’t have to hard-code product lists, but also gave us the ability to A/B test marketing messages and pricing strategies with just a few clicks. On top of that, the unified reporting across platforms makes it far easier to get a single picture of subscriptions and revenue. And the fact that RevenueCat ships with a Kotlin Multiplatform (KMP) SDK was a huge bonus - integrating it into our existing architecture was smooth and developer-friendly.

What Billin offers

At its core, Billin is an invoicing tool designed to help freelancers and small businesses manage their billing process on mobile. The app supports:

Invoice creation – generate invoices with support for taxes, discounts, and automatic totals.
Tracking and Reporting – keep a record of payments, overdue items, expenses, and client summaries.
Entities Management – maintain items and services you offer for quick invoice creation.
Cross-Platform Access – preview invoices as PDFs or images, share them securely, and access data from multiple devices.

This functionality is wrapped in a design that is clean and modern, intentionally not tied too closely to either Android or iOS design systems, while still using native UI elements and animations to feel natural on each platform.

The power of CMP

For us, Compose Multiplatform (CMP) wasn't just about writing less code. They were about creating a seamless cross-platform experience while keeping our development process lean and scalable.

Billin today is both a native Android app and a wonderful iOS app , built from the same shared foundation. With thoughtful adjustments, it feels fully integrated into each ecosystem while maintaining a consistent experience across platforms. Combined with our Kotlin/Spring backend and monorepo approach, we’ve created a unified stack where models, logic, and services can be reused everywhere.

This approach has allowed us to move faster, reduce duplication, and deliver apps that feel at home on both Android and iOS while staying true to a clean, platform-agnostic design.

Navigate back with results in Jetpack Compose Navigation

RockAndNull — Fri, 19 Sep 2025 08:57:31 +0000

If you’ve ever needed to open a screen, let the user pick something, and then pass that selection back to the previous screen, you probably reached for shared ViewModels, singletons, or brittle route parameters.

There’s a simpler way that works with Jetpack Compose Navigation: navigate forward → wait for a result → navigate back with that result.

This post introduces a tiny helper you can drop into your project and explains how it works, complete with examples, pitfalls, and testing tips.

The Helper

Put this file somewhere in your project as-is.

import androidx.lifecycle.Lifecycle
import androidx.lifecycle.LifecycleEventObserver
import androidx.lifecycle.LifecycleOwner
import androidx.navigation.NavController
import kotlin.coroutines.resume
import kotlinx.coroutines.suspendCancellableCoroutine
import kotlinx.serialization.json.Json

private const val RESULT_KEY = "result"

fun <T> NavController.navigateBackWithResult(value: T) {
    previousBackStackEntry?.savedStateHandle?.set(RESULT_KEY, value)
    navigateUp()
}

inline fun <reified T> NavController.navigateBackWithSerializableResult(value: T) {
    navigateBackWithResult(Json.encodeToString(value))
}

suspend fun <T> NavController.navigateForResult(route: Any): T? =
    suspendCancellableCoroutine { continuation ->
        val currentNavEntry = currentBackStackEntry
            ?: throw IllegalStateException("No current back stack entry found")

        navigate(route)

        val lifecycleObserver = object : LifecycleEventObserver {
            override fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event) {
                if (event == Lifecycle.Event.ON_START) {
                    continuation.resume(currentNavEntry.savedStateHandle[RESULT_KEY])
                    currentNavEntry.savedStateHandle.remove<T>(RESULT_KEY)
                    currentNavEntry.lifecycle.removeObserver(this)
                }
            }
        }

        currentNavEntry.lifecycle.addObserver(lifecycleObserver)

        continuation.invokeOnCancellation {
            currentNavEntry.savedStateHandle.remove<T>(RESULT_KEY)
            currentNavEntry.lifecycle.removeObserver(lifecycleObserver)
        }
    }

suspend inline fun <reified T> NavController.navigateForSerializableResult(route: Any): T? {
    val result: String = navigateForResult(route) ?: return null
    return Json.decodeFromString(result)
}

NavigateBackWithResult.kt

How it works

Caller launches a route with navigateForResult(route). The current entry is remembered, navigation occurs, and a lifecycle observer is set up.
Callee finishes by calling navigateBackWithResult(value). The result is stored in the caller’s SavedStateHandle under a fixed key.
Caller resumes on ON_START. The coroutine unblocks, retrieves the result, and clears the key to avoid stale values.

This is lifecycle-aware, type-safe, and minimal - no ActivityResultContract, no shared ViewModel, no event bus.

How to use it

Here's a simple example to see the pattern in action. Imagine a screen where the user picks a color, and when they go back, the chosen value is passed to the previous screen. This is the most straightforward case: a basic type (String) being sent back.

// Routes:

object Routes {
    const val HOME = "home"
    const val COLOR_PICKER = "color-picker"
}

// Nav host:

@Composable
fun AppNavHost(navController: NavHostController = rememberNavController()) {
    NavHost(navController, startDestination = Routes.HOME) {
        composable(Routes.HOME) { HomeScreen(navController) }
        composable(Routes.COLOR_PICKER) { ColorPickerScreen(navController) }
    }
}

// Caller (HomeScreen):

@Composable
fun HomeScreen(navController: NavController) {
    val scope = rememberCoroutineScope()
    var selectedColor by remember { mutableStateOf<String?>(null) }

    Column(Modifier.padding(16.dp)) {
        Text("Selected: ${'$'}{selectedColor ?: "none"}")
        Button(onClick = {
            scope.launch {
                val result: String? = navController.navigateForResult(Routes.COLOR_PICKER)
                selectedColor = result
            }
        }) {
            Text("Pick color")
        }
    }
}

// Callee (ColorPickerScreen):

@Composable
fun ColorPickerScreen(navController: NavController) {
    val colors = listOf("Red", "Green", "Blue")
    Column(Modifier.padding(16.dp)) {
        colors.forEach { color ->
            Button(onClick = { navController.navigateBackWithResult(color) }) {
                Text(color)
            }
        }
        OutlinedButton(onClick = { navController.navigateUp() }) {
            Text("Cancel")
        }
    }
}

Edge cases and gotchas

There are a few edge cases and nuances worth keeping in mind. Results are always nullable (T?), so you should be prepared to handle the case where the user cancels or navigates back without setting anything. If you use the non-serializable variant and the caller and callee don’t agree on the type, you’ll hit a ClassCastException, so type alignment is critical. Results also don’t survive process death, since this mechanism is essentially a callback rather than persistent state. Finally, avoid waiting for multiple results concurrently from the same destination; if you need that, wrap access in your own guard or queue to prevent conflicts.

Conclusion

This helper gives you a lightweight, lifecycle-aware pattern for passing data back through the Compose Navigation stack: you simply drop it into your project, call navigateForResult() when moving forward, and then call navigateBackWithResult() when returning. That’s all it takes - no extra contracts and no brittle hacks.

Happy coding!

AI everywhere: The hype, the misfits, and the inevitable maturity

RockAndNull — Thu, 04 Sep 2025 13:40:30 +0000

Artificial Intelligence is here to stay. But right now, it’s being added to everything - whether it’s a good fit or not.

I’ve seen this before. When mobile was the big trend, businesses rushed to build apps simply because everyone else was. Most of those apps added no value and quickly faded. When crypto was hot, simple systems that could have been handled by a database suddenly had “blockchain” bolted onto them - just because it sounded innovative.

AI is going through the same phase. A recent MIT report noted that 95% of AI investments generate zero return, usually because they’re solving problems that don’t need AI in the first place. The result is wasted time, wasted money, and features no one uses.

But this cycle is normal. Technologies go from hype → misapplication → maturity. Over time, the buzzwords disappear, and the tech just becomes infrastructure. Nobody says “we use machine learning” when their photos are tagged automatically - they just say “face recognition.” AI will follow the same path.

As the saying goes, "AI is whatever hasn't been done yet". Once it works, it’s just part of the product.

Focus on solving real problems, and the right technology - AI or not - will find its place.

Big clients aren’t always a big win

RockAndNull — Thu, 24 Jul 2025 14:14:16 +0000

At first, it feels great. A big client, the kind you might call a “whale”, signs on. Revenue spikes, your roadmap gets direction, and there’s a sense of security. After all, what could go wrong with landing a massive account?

But let’s be honest: “whales” aren’t always the win they seem to be. Sometimes, they’re a trap.

We’ve seen it firsthand and talked about it again recently — mostly as a reminder to ourselves. When a single client becomes too important to your business, you're not scaling — you're becoming dependent. And dependency is the opposite of stability.

When one client controls too much of your revenue, they also start to control your priorities. They might dictate timelines, influence your product direction, and make demands that smaller clients would never dare. Suddenly, you're no longer building your own company — you're building theirs.

And if that whale ever swims away? You’re in deep water.

There’s more long-term health in a diverse client base, a balanced ecosystem with many smaller (but consistent) clients. It might not feel as glamorous, but it’s sustainable. You gain resilience. You avoid single points of failure. You keep your team and your product focused on a broader vision, not the whims of one massive account.

This isn’t to say big clients are bad. They can be incredible partners when the relationship is healthy and well-bounded. But the moment a whale starts to define your business, it’s worth taking a step back.

So if you’ve landed one — great. Celebrate the win. But also, build your raft.