Hey folks, Jamie here again.

So, we've talked APIs, authentication, deployment... core backend and infrastructure stuff. But let's be honest, if you're coming to Flutter from a web background (especially PHP/Laravel like me), one of the first conceptual hurdles you'll likely encounter isn't fetching data, it's managing state within the app itself.

On the web, particularly with traditional frameworks, state often feels more segmented. We have request state (data tied to a single HTTP request), session state (user-specific data stored server-side), maybe some client-side JavaScript state for UI interactions, and of course, the database as the ultimate source of truth.

Flutter, being a declarative UI framework focused on building interfaces from application state, requires a more explicit and often more granular approach. Widgets rebuild based on state changes, and figuring out where that state should live and how different parts of your app should access or modify it is crucial. Get it wrong, and you can end up with spaghetti code, performance issues, or just general confusion.

Ephemeral vs. App State: The Big Divide

Flutter's own documentation makes a helpful distinction:

• Ephemeral State: State that's neatly contained within a single widget (or maybe a widget and its direct children). Think: the current page in a PageView, the animation progress of a complex button, the text in a specific form field before submission. Often, Flutter's built-in StatefulWidget and its setState() method are perfectly adequate for this. Simple, local, effective.
• App State: State that needs to be shared across different parts of your widget tree. Think: user authentication status, shopping cart contents, application settings, data fetched from your Laravel API that multiple screens need to display. This is where setState() becomes unwieldy, leading to prop-drilling (passing data down many layers) or complex callback chains. This is where dedicated state management solutions shine.

Navigating the Options: A Quick Tour

When you need to manage App State, the Flutter ecosystem offers several popular choices. Here's a very high-level look from a web dev's perspective:

1. setState (and StatefulWidget):

   • Analogy: Think basic JavaScript manipulating the DOM directly within a small component.
   • Use Case: Great for purely local, ephemeral state within a single widget.
   • Pros: Built-in, simple for basic cases.
   • Cons: Doesn't scale for sharing state; leads to prop-drilling or complex callbacks if misused for app state.

2. Provider:

   • Analogy: A bit like dependency injection containers or service locators common in backend frameworks. It makes “services” (like a user repository or cart manager) available deeper down the widget tree without manually passing them.
   • Use Case: Sharing app state, dependency injection. Often considered a good starting point.
   • Pros: Relatively simple concept, less boilerplate than some others, widely used, good documentation. Built on Flutter's InheritedWidget.
   • Cons: Can sometimes feel a bit “magic,” potential for runtime errors if providers aren't set up correctly above the widgets that need them.

3. Riverpod:

   • Analogy: Think of it as Provider's sophisticated sibling, addressing some of Provider's limitations. Still handles dependency injection and state access but aims for more compile-time safety and flexibility.
   • Use Case: Similar to Provider, but often preferred for larger or more complex apps due to its features.
   • Pros: Compile-time safe (fewer runtime errors), more flexible (providers aren't tied directly to the widget tree), testable, actively developed.
   • Cons: Slightly steeper learning curve than Provider initially, concepts might feel a bit abstract at first.

4. Bloc / Cubit (using the flutter_bloc package):

   • Analogy: This feels closest to more structured patterns like MVC/MVVM often seen in backend or other frontend frameworks. It enforces a clear separation between UI (widgets), business logic (Blocs/Cubits), and data layers. Events/Methods trigger state changes in a predictable stream.
   • Use Case: Complex state logic, enforcing clear architecture, applications where testability is paramount.
   • Pros: Excellent separation of concerns, highly testable, predictable state transitions, scales very well for large teams/projects. Cubit offers a simpler, less boilerplate-heavy version for straightforward cases.
   • Cons: Can involve more boilerplate code compared to Provider/Riverpod, might feel like overkill for very simple apps.

The Pragmatic Take

So, which one should you use? As always, the pragmatic answer is: it depends.

• For truly local state, setState is fine.
• Provider is a solid, accessible starting point for sharing app state.
• Riverpod offers more safety and flexibility, making it a compelling choice, especially as apps grow.
• Bloc/Cubit provides the most structure and testability, ideal for complex scenarios or teams that value strict architectural patterns.

Coming from Laravel, the structure of Bloc might feel somewhat familiar if you're used to well-defined services and maybe event-driven systems. However, the reactive nature and compile-time safety of Riverpod are also very appealing.

My advice? Start simple (maybe Provider or Riverpod's basics). Understand the core problem of lifting state up. Then, explore the others as your app's complexity grows. Read their docs, try their examples, and see which one clicks best with your way of thinking. There's no single “best” solution, only the best fit for your project and team.

What are your go-to state management solutions in Flutter, especially if you've come from a web background? Let me know your thoughts!

Cheers,

Jamie C.

Hey everyone, Jamie here. Hope you all had a decent Easter break! Back in the saddle now, and after a bit of downtime, the focus inevitably shifts back to shipping features. And shipping features means... deployment.

Ah, deployment. It might not have the creative thrill of building a new feature, but getting your code reliably and safely from your machine into the hands of users is arguably one of the most critical parts of the whole process. Especially when you're juggling both a backend API (hello, Laravel!) and a mobile frontend (our friend, Flutter). It's not just one deployment; it's (at least) two coordinated dances.

So, let's talk practical strategies for deploying both parts of our stack without pulling our hair out.

Part 1: The Laravel Side – Keeping the API Ship Sailing Smoothly

Our Laravel API is the engine room. Deploying it typically involves updating code on a server, running commands, and ensuring the database is in sync. The goal? Automation, reliability, and minimal (ideally zero) downtime.

While the specific tools vary (and developers have strong opinions!), the process often involves similar steps.

• Common Tooling: You might be using services like Laravel Forge, Ploi, or RunCloud to provision and manage your servers. For the deployment itself, maybe Laravel Envoyer for zero-downtime PHP deployments, the open-source Deployer (PHP), custom scripts triggered via GitHub Actions, or even platforms like Laravel Vapor if you're going serverless. Docker (often via Laravel Sail locally) also plays a big role in ensuring environment consistency from development through to production.
• The Pragmatic Checklist (Automate This!): Regardless of the tool, your deployment script must handle key tasks reliably:
  • Pull the latest code (git pull).
  • Install/update backend dependencies (composer install --no-dev --optimize-autoloader).
  • Install/build frontend assets if needed (npm install && npm run build).
  • Manage environment variables (.env file) securely – never commit secrets! Use the tooling's environment management.
  • Run database migrations: php artisan migrate --force (the --force is crucial in production).
  • Clear relevant caches: php artisan config:cache, php artisan route:cache, php artisan view:clear. Maybe php artisan optimize depending on your workflow.
  • Restart queue workers if you use them (php artisan queue:restart).

The key takeaway here is automation and repeatability. Script these steps. Use a deployment tool. Remove manual SSH commands as much as possible to reduce errors.

Part 2: The Flutter Side – Getting the App onto Devices

Deploying a Flutter app is a whole different kettle of fish. We're compiling native code, dealing with app stores, code signing, and review processes.

• CI/CD is Your Best Friend: Manually building, signing, and uploading Flutter apps is tedious and error-prone. Continuous Integration and Continuous Deployment (CI/CD) pipelines are practically essential.
  • Popular Choices: Codemagic is excellent and Flutter-focused. GitHub Actions is incredibly versatile and popular. Bitrise is another strong mobile CI/CD platform. You can also script local automation using Fastlane.
• The Pragmatic Pipeline: A typical Flutter CI/CD pipeline should:
  • Checkout the code.
  • Set up the correct Flutter version.
  • Install dependencies (flutter pub get).
  • Run tests! (flutter test). Don't skip this!
  • Build the release artifact (flutter build appbundle --release for Android, flutter build ipa --release for iOS).
  • Handle Code Signing: This is often fiddly but unavoidable. Securely manage your .jks file (Android) and provisioning profiles/certificates (iOS) using secrets management in your CI/CD platform (e.g., GitHub Secrets, Codemagic encrypted variables).
  • Distribute to Testers: Automatically deploy builds to TestFlight (iOS) and Google Play Internal/Closed Testing tracks. Get feedback before going live.
  • Deploy to Production: Automate uploads to the App Store and Google Play (e.g., using Fastlane deliver/supply actions, or specific platform integrations).

Remember to factor in app store review times (especially for iOS). You can't just push a button and have it live instantly.

Part 3: The Coordination Challenge – Making Them Dance Together

Okay, we have two separate deployment processes. The real trick is making them work in harmony. A new app feature often requires both backend API changes and frontend UI changes. Deploying them out of sync can break things for users.

• API Versioning is CRITICAL: I mentioned this in the API design post, and it's vital for deployment. Your new Flutter app (v1.1) might need /api/v2/feature, but users still running the old app (v1.0) will be hitting /api/v1/feature. Your backend must support both during the transition, either via explicit versioning (/api/v1, /api/v2) or careful backward-compatible changes.
• Staging Environment is Mandatory: You need a dedicated staging environment that mirrors production. Here, you deploy the release candidate of your Laravel API and install the release candidate build of your Flutter app. Test the entire user flow thoroughly before anything goes to production.
• The Usual Release Order: Based on painful experience and general best practice (confirmed by others online too!):
  1. Deploy the Backend Changes First: Get your /api/v2 endpoints live, while ensuring /api/v1 (or backward compatibility) remains functional for existing app users. Monitor the deployment closely.
  2. Submit New App to Beta: Once the backend is stable, submit the new Flutter app build (which uses the /api/v2 endpoints) to TestFlight and Google Play's testing tracks.
  3. Test, Test, Test: Rigorously test the new app build against the new API endpoints in staging and via your beta testing groups.
  4. Release App to Production: Once confident, promote the Flutter app release to production in the respective app stores.
  5. Monitor: Keep an eye on analytics and error reporting as users adopt the new version.
  6. (Eventually) Sunset Old API: Months later, once most users have updated (or you implement a force-update mechanism), you can consider scheduling the removal of the old /api/v1 endpoints. Don't rush this!
• Consider Feature Flags: To further decouple, you can deploy backend code changes behind feature flags. The code is live but inactive until you enable the flag (often coordinated with the app release).
• Communicate (Even with Yourself!): Whether you're a solo dev or part of a team, have a clear deployment plan or checklist. Document the steps. It prevents “Oops, I forgot to restart the queue worker” moments at 5 PM on a Friday.

Wrapping Up

Deploying a full-stack Laravel/Flutter application requires discipline. It means managing two distinct pipelines and, crucially, coordinating their releases carefully. Planning, automation (especially for CI/CD), thorough testing in a staging environment, solid API versioning, and a dose of patience (thanks, app stores!) are your keys to success.

What are your favourite deployment tools or strategies for this kind of stack? Any war stories or hard-won lessons to share? Let's chat in the comments!

Cheers,

Jamie C

Hi folks, Jamie here again.

Last time we chatted about authentication – getting users securely logged into our applications. Today, let's talk about what happens after they're logged in: consuming data via APIs.

If you're building a Laravel backend to power a Flutter mobile app (or any mobile app, really), just throwing together some resource controllers that map directly to your database tables often isn't enough. Mobile clients have different needs than web browsers: they operate over potentially flaky or slow networks, have smaller screens influencing data display, and can't easily make dozens of requests to stitch together a view.

Designing a good API – one that's efficient, predictable, and easy for your Flutter app to consume – requires some specific thought. Here are some practical tips from my experience building Laravel backends for mobile frontends.

1. Think Beyond Raw Database Models: Use Transformation Layers

Your database schema is optimised for storage and relationships, not necessarily for direct display on a mobile screen. A single screen in your Flutter app might need data combined from multiple models, or fields formatted in a specific way.

Don't just return raw Eloquent models. This leaks internal structure and often sends way more data than needed.

Do leverage Laravel's API Resources. These are fantastic transformation layers. They allow you to define precisely how your models should be represented as JSON, letting you:

• Rename attributes ('user_name' => $this->name).
• Add related data conditionally ($this->mergeWhen(...)).
• Include computed properties or links.
• Maintain consistency across your API responses.

Start using API Resources early; they make your API cleaner and decouple your frontend from your database structure.

2. Keep Payloads Lean: Mind the Mobile Network

Every byte counts on mobile networks. Sending huge JSON payloads drains battery, consumes data allowances, and makes your app feel sluggish.

• Be Selective: Use your API Resources (see Tip 1!) to only include the fields the client actually needs for a given view. Avoid select * mentality.
• Prevent N+1 Queries: On the backend, excessive database queries dramatically slow down response times. Use Laravel's eager loading (->with('relation')) religiously in your controllers before passing data to your API Resource. Tools like Laravel Debugbar or Telescope can help spot N+1 issues.
• Consider Sparse Fieldsets: For more advanced cases, allow clients to request only specific fields, e.g., /api/v1/posts?fields[posts]=title,author. JSON:API specs offer guidance here, though implementing it fully adds complexity.

3. Handle Relationships Intelligently

How do you include related data (e.g., a post's author and comments)?

• Embedding: Include related resources directly within the main resource response. API Resources make this easy ('author' => new UserResource($this->whenLoaded('author'))). — Pro: Reduces the number of HTTP requests the client needs to make. — Con: Can significantly increase payload size if you embed too much or too deeply.
• Linking: Include only the IDs of related resources and require the client to make separate requests if needed. — Pro: Keeps initial payloads small. — Con: Can lead to a “chatty” API requiring many requests to build a single screen.

Find the balance. Embed essential, commonly needed relationships (like the author of a post). Link to less critical or potentially large collections (like comments, which might be loaded on demand). Use whenLoaded in your API Resources to only include relations if they were eager-loaded in the controller.

4. Implement Sensible Pagination

Your Flutter app probably uses infinite scrolling or “load more” buttons for long lists. Your API needs to support this efficiently.

• Use Laravel's Pagination: Don't fetch all records at once! Use ->paginate() or ->simplePaginate() in your controllers. simplePaginate is often slightly more efficient as it only generates “next” and “previous” links, which is usually enough for mobile UIs.
• Provide Clear Metadata: Ensure your API response includes clear pagination information (current page, next page URL, total items if using paginate). Laravel's paginator objects, when returned directly or wrapped in an API Resource, handle this automatically.

5. Design for Predictable Error Handling

When things go wrong (and they will), your Flutter app needs to know what went wrong to display useful feedback or attempt recovery.

• Use HTTP Status Codes Correctly: Don't just return 200 OK with an {'error': '...'} payload. Use standard codes: — 400 Bad Request: Generic client error. — 401 Unauthorized: Missing or invalid authentication. — 403 Forbidden: Authenticated but lacks permission. — 404 Not Found: Resource doesn't exist. — 422 Unprocessable Entity: Validation errors (Laravel's specialty!). — 500 Internal Server Error: Something broke on the backend.
• Provide Meaningful Error Payloads: Especially for 422 validation errors, return a structured list of errors keyed by field name (Laravel does this by default). For other errors, a simple {'message': 'Human-readable error'} payload is often sufficient.
• Leverage Laravel's Exception Handler: Customize App\Exceptions\Handler.php to render your API exceptions into consistent JSON error responses.

6. Version Your API from Day One

Mobile apps live on user devices, and you can't force everyone to update instantly. If you change your API in a way that breaks older versions of your app, you'll have unhappy users.

Introduce API versioning right from the start (e.g., prefixing your routes with /api/v1/). This allows you to evolve your API (/api/v2/) while maintaining compatibility for older deployed app versions.

Quick Mention: What About GraphQL?

We've focused on REST principles here. It's worth mentioning GraphQL as a powerful alternative. Its main strength is allowing the client (your Flutter app) to request exactly the data fields and relationships it needs in a single query, potentially solving over-fetching and under-fetching issues inherent in REST. Libraries like Lighthouse PHP make adding a GraphQL layer to Laravel quite elegant. While potentially overkill for simple APIs, it's definitely worth investigating for complex data requirements.

Conclusion

Building an API for mobile clients isn't rocket science, but it pays to be thoughtful. By leveraging Laravel's API Resources, mindful data loading, consistent error handling, and versioning, you can create APIs that are a joy for your Flutter frontend (and its developers!) to consume. Focus on the client's needs, keep things efficient, and aim for predictability.

What are your go-to API design tips when working with Laravel and mobile frontends?

Cheers,

Jamie C.

Hey everyone, Jamie here again.

So, you've built a slick Laravel backend. Your database is structured, your business logic is humming along... but now you need to let users log in. If you're only dealing with traditional server-rendered web pages, Laravel's built-in session authentication is fantastic – simple, secure, and gets the job done.

But what happens when your clients aren't just web browsers? What about Single Page Applications (SPAs) built with Vue or React, or native mobile apps built with Flutter, like we often discuss here? Suddenly, session cookies aren't always the neatest solution. This is where things get interesting, and where tools like Laravel Sanctum step into the spotlight, alongside powerful third-party options.

Let's dive into some authentication strategies for these modern application stacks.

The Challenge: Authenticating SPAs and Mobile Apps

Traditional session-based authentication relies on cookies tightly coupled to your web domain. This works great when the browser and server are on the same domain. However:

• SPAs: Often served from a different domain or port than the API backend, making cookie sharing tricky due to browser security policies (CORS, SameSite cookies).
• Mobile Apps (Flutter, etc.): These aren't browsers! They don't inherently handle cookies in the same way, and making HTTP requests requires a different approach, usually involving tokens.

This leads us towards token-based authentication. The client logs in, receives a token, and includes that token in the header of subsequent requests to prove its identity. Laravel has long offered Passport for full OAuth2 server implementation, which is powerful but can be overkill for simpler first-party scenarios.

Enter Laravel Sanctum: The Lightweight Powerhouse

This is exactly where Laravel Sanctum comes in. Introduced as a simpler alternative to Passport, Sanctum is designed specifically to solve authentication for SPAs, mobile apps, and simple token-based APIs.

Here's why I often find myself reaching for Sanctum:

• Simplicity: Compared to setting up a full OAuth2 server with Passport, Sanctum is significantly easier to configure and understand. Fewer moving parts mean less complexity.
• Brilliant SPA Authentication: Sanctum provides a beautifully simple way to authenticate your SPAs if they live on the same top-level domain as your backend. It cleverly uses Laravel's existing session authentication system (cookie-based) but handles the necessary CSRF protection and SameSite cookie configurations, making it feel almost seamless. Your SPA frontend makes requests just like a traditional web app.
• Effortless API Token Authentication: This is key for mobile apps (like our Flutter projects!) or any third-party consumer of your API. Sanctum allows users to generate API tokens (either long-lived personal access tokens or shorter-lived tokens tied to OAuth flows if needed, though typically used more simply). These tokens can be assigned specific “abilities” (scopes) for granular permission control. Your Flutter app just needs to store this token securely and send it along in the Authorization: Bearer header. Easy peasy.
• Tight Laravel Integration: It feels like a natural part of the framework because it is. It leverages existing Laravel components (middleware, guards, user model) seamlessly.
• Full Control: You manage the entire authentication flow, user database, and token lifecycle within your own application. You own your data and the logic.

Sanctum is often my go-to choice when:

• Building a first-party SPA that communicates with its own Laravel API.
• Creating a backend API specifically for consumption by my own Flutter mobile application.
• Needing a simple, secure token system without the full baggage of OAuth2 grants.

Considering the Alternatives: Third-Party Heroes (Auth0, etc.)

Now, Sanctum is great, but it's not the only game in town. Sometimes, offloading authentication entirely to a dedicated third-party service makes more sense. Think platforms like Auth0, Okta, Firebase Authentication, AWS Cognito, and others.

These services specialize purely in identity management. Here's why you might consider them:

• Rich Feature Set: They often come packed with features that would take significant time to build yourself: robust multi-factor authentication (MFA), extensive social login options (Google, Facebook, GitHub, etc.), passwordless login, anomaly detection, sophisticated user management dashboards, compliance certifications.
• Reduced Security Burden: Handling password hashing, secure storage, reset flows, and staying ahead of vulnerabilities is their core business. Offloading this can reduce your own security surface area.
• Scalability & Reliability: These platforms are built to handle authentication at massive scale.
• Standard Protocols: They usually fully implement standards like OAuth2 and OpenID Connect, which can be beneficial for complex integration scenarios or B2B applications.

However, there are trade-offs:

• Cost: Pricing is often per-user or per-active-user, which can become significant at scale.
• Vendor Lock-in: Integrating deeply means migrating away later can be challenging.
• Less Control / Data Residency: Your user data lives on their platform, and you rely on their infrastructure and feature roadmap.
• Integration Complexity: While they aim for simplicity, integrating their SDKs and managing the callback flows can still involve its own learning curve.

A third-party provider might be the better choice if:

• You need features like social logins or advanced MFA right now.
• You want to heavily offload the security and operational burden of identity management.
• You're operating in a highly regulated environment requiring specific certifications.
• Your budget accommodates their pricing model.

Making the Call: Context is King

There's no single “best” answer.

• For straightforward first-party SPAs and mobile apps talking to your Laravel API, Laravel Sanctum often hits the sweet spot. It provides elegant solutions for both web and mobile clients, keeping things simple, integrated, and under your control.
• If your needs are more complex, require rapid integration of many third-party logins, or if you want to completely abstract away the identity layer, exploring services like Auth0 is definitely worthwhile.

Think about your project's specific requirements, your team's expertise, your budget, and your long-term control needs. Both approaches are valid and powerful when used in the right context.

What are your experiences? Do you lean towards Sanctum or third-party providers for your Laravel-powered APIs? Let me know in the comments!

Cheers,

Jamie C.

Hi everyone, Jamie Carmichael here. Thrilled to finally launch my new blog, The Pragmatic Pixel!

So, a quick backstory: I've spent years building web applications, mostly deep in the PHP and Laravel world – stuff I genuinely enjoy for crafting solid backends. But like many, I got pulled towards cross-platform development and landed squarely with Flutter for building mobile UIs.

Why start this blog now?

Honestly, it feels like the right moment. I've spent enough time working at the intersection of Laravel and Flutter on real projects – designing APIs, figuring out auth flows, debating state management from both perspectives – that I've built up a stash of practical insights, workarounds, and opinions.

I kept finding myself wishing there was one place that consistently tackled the specific challenges of making these two powerful ecosystems play nicely together. Instead of just wishing, I figured, why not build it?

So, The Pragmatic Pixel is born out of that need: a place to share practical tips, tutorials, and real-world learnings focused specifically on bridging the gap between robust PHP backends and fluid Flutter frontends.

It's time to start documenting and sharing what I'm learning in the trenches. Hope you'll follow along!

More content coming very soon.

Cheers,

Jamie C.

Hey everyone, and welcome!

I'm Jamie Carmichael, and this is the very first post on my new blog, The Pragmatic Pixel. It's incredibly exciting to finally hit 'publish' and start sharing my thoughts and experiences with you all.

For years, my professional world has revolved around building scalable and reliable web applications. Like many of you, I've spent countless hours deep in the world of PHP, particularly leveraging the elegance and power of the Laravel framework. It's a fantastic ecosystem for crafting robust backends, APIs, and complex web platforms – it's been the engine behind numerous projects I've built, both for my own small consultancy and for clients.

But the tech landscape is always evolving, isn't it? A few years back, the siren call of cross-platform mobile development became too loud to ignore. I wanted a way to build beautiful, performant, native-feeling apps for both iOS and Android without necessarily maintaining two entirely separate codebases. My exploration led me, perhaps inevitably, to Flutter. The developer experience, the declarative UI paradigm, and the sheer potential hooked me almost immediately.

Bridging Two Worlds

And that's really the why behind The Pragmatic Pixel.

While there are countless excellent resources dedicated solely to PHP/Laravel or solely to Flutter, I often found myself grappling with the challenges and opportunities that arise right at the intersection of these two powerful technologies.

• How do you best structure a Laravel API specifically for consumption by a Flutter app?
• What are the most effective authentication patterns (Sanctum, Passport?) when bridging this gap?
• How do concepts from backend development translate (or not!) to state management in Flutter?
• What are the practical deployment pipelines for a full-stack application built this way?

This blog is my space to document my journey exploring these questions, sharing solutions, and offering practical insights gained from real-world projects.

What to Expect Here

My goal is to be pragmatic. We'll be focusing on:

• Practical Tutorials: Step-by-step guides on integrating Laravel backends with Flutter frontends.
• Architectural Discussions: Thoughts on structuring full-stack applications using these technologies.
• API Design: Best practices for creating APIs that are efficient and easy for Flutter to consume.
• Tooling & Deployment: Exploring workflows, CI/CD, and hosting solutions for both parts of the stack.
• Comparisons & Opinion Pieces: Honest takes on different approaches, libraries, and state management techniques, always grounded in experience.
• Occasional Musings: Thoughts on the broader software development landscape, viewed through the lens of someone working across the stack.

Who Is This For?

If you're:

• A PHP/Laravel developer curious about adding Flutter to your skillset.
• A Flutter developer looking for robust backend solutions or coming from a web background.
• Anyone interested in the practicalities of building and deploying modern, cross-stack applications.

...then I hope you'll find value here. Let's Get Started!

I'm genuinely excited to build this space and share what I'm learning. Technology is more fun when it's a conversation, so please feel free to leave comments, share your own experiences, or suggest topics you'd like to see covered.

For now, thanks for stopping by!

Cheers,

Jamie C.