Hey everyone,

I recently got laid off, and with the current job market tightening up—fewer new projects and heavy competition for mid/senior roles. I’m taking a hard look at where to steer my career next.

I’m weighing three distinct directions and would appreciate candid advice and reality checks:

1. 1. Double down on Flutter & Mobile
   • Is Flutter still a dependable primary specialization for the next 3–5 years, or is it becoming too risky on its own?
   • I’ve been exploring full-stack Dart with Serverpod to broaden my skill set, but realistically, the job market for it is practically non-existent since it's so new.
   • For those sticking with Flutter, what viable adjacent skills are you adding (e.g., traditional backends like Go/Node, system design) to stay competitive?
2. 2. Pivot toward AI Engineering
   • Hiring reality: Do companies actually hire "AI Engineers" who don't have prior professional ML/AI experience, or do they mostly require senior backend backgrounds or advanced CS/math degrees?
   • Roadmap & entry point: Coming from a Flutter dev background, what does a practical, hireable roadmap look like? What specific tech stacks, core concepts (e.g., Python backends, RAG, tool calling, agentic workflows, evals), and resources would you recommend to build a job-ready portfolio?
3. 3. Switch to React (JS/Native) or Native App Development (Kotlin/Swift)
   • UI architecture, state management, mobile lifecycles, and performance optimization are fundamentally similar across frameworks, so this feels like the most direct way to leverage my existing Flutter experience.
   • Hiring reality: How do recruiters and hiring managers view this transition? Do they treat mobile/frontend fundamentals as transferable, or do resume screens filter you out for lacking "X years of commercial React / Kotlin / Swift experience"?
   • Where to focus: Between the React ecosystem (React.js + React Native for broader web/cross-platform volume) and Native (Kotlin/Swift for deeper platform specialization), which path has proven more practical for devs leaping recently?
   • What’s the fastest, most effective way to prove competence without commercial experience in those exact stacks?

Has anyone here successfully navigated a pivot from Flutter to AI engineering or React/Native recently? Any roadmaps, project ideas, or harsh truths would be greatly appreciated.

I tried quite a few libraries to run GGUF models on Android, but none really matched my expectations.

Apple's ecosystem feels more unified for on-device ML, with Core ML and MLX. On Android, the options and guidelines feel more scattered, and getting different models running without extra hassle isn't always straightforward.

So I decided to build Kiln, which is a C inference layer built on top of llama.cpp, with language bindings for Flutter, Kotlin, React Native, and more. It's too easy now to run a model with kiln.

The goal is simple: make running local AI models on mobile less painful.

It's open source, and I'd love to hear what other developers think or what could be improved.

It's available in pub dev too: kiln_flutter

GitHub: https://github.com/RaihanulHaque/kiln

Sync was the hardest part of my Flutter app by far. Most of my bugs were around auth, migrations, reconnecting, offline changes and getting two devices to agree.

The app is Personal Planner, a free planner for Linux, Android, Windows and macOS: hour-by-hour Day view with timers, daily and weekly reviews, a consistency heatmap, Experiments and an Inbox. First Flutter project for me.

How it's put together:

- **Local first.** Drift on SQLite is the everyday store. Moving a block, finishing a task, starting a timer or opening an old day never waits on a server

- **A local outbox.** Anything that still needs to sync waits there until the connection is back, and a sync engine pushes it to Supabase PostgreSQL

- **Supabase Auth** for sign-in, Riverpod for state

- **Provisioning.** A usable Supabase project needs the right schema, migrations, access rules and client config, and doing that by hand is painful. So a Cloudflare Worker does it from inside the app: connects your Supabase account, reuses a compatible project or creates one, applies the migrations and verifies the schema. Setup has several steps, so Durable Objects keep its state in between. After that the Worker is out of the picture and the app talks to Supabase directly

Two things I hit on desktop:

- On Windows, setup failed with CERTIFICATE_VERIFY_FAILED. Windows didn't trust the root certificate needed to reach Supabase, and updating Windows plus \certutil -generateSSTFromWU roots.sst` fixed it`

- The \com.personalplanner.personalplanner://` link scheme isn't registered on Windows and macOS yet, so the sign-up confirmation email and the provisioning authorization links can't open the app there. Email and password sign-in works fine`

Windows and macOS are built and smoke-tested on GitHub Actions. Both are unsigned, and macOS is CI-only because I don't own a Mac.

Download: https://github.com/Karthikshabari/PersonalPlanner/releases

Code: https://github.com/Karthikshabari/PersonalPlanner (the README has the architecture diagram). Dev here.

Hi everyone

I'm conceptualizing a feature where users can completely transform an app or web interface using custom, downloadable "RPG-themed" extension packs from official repositories.

The core idea revolves around:

External Theme Plugins: Allowing users to download theme files (e.g., JSON-based configuration packs) from an official website and import them seamlessly.

Advanced Color Gradients: Implementing a dynamic color engine that smoothly transitions and interpolates complex color palettes defined by the user or the plugin.

RPG UI Metaphors: Structuring the design tokens to mimic fantasy/RPG interface elements without breaking performance.

From a software architecture perspective, what is the best way to safely parse external theme plugins, handle dynamic color tokens, and apply them across components without causing performance bottlenecks?

I'd love to hear your thoughts and technical recommendations. Constructive feedback is very welcome!