Forem: Drew Marshall

I Got Tired of Class-Heavy UI Code… So I Kept Going (Juice Part 2)

Drew Marshall — Sun, 19 Apr 2026 11:54:00 +0000

In my last post, I talked about why I started building Juice—mainly out of frustration with class-heavy UI code and how messy things can get as projects scale.

If you haven’t read that yet, here it is:
👉 https://dev.to/stinklewinks/i-got-tired-of-class-heavy-ui-code-so-i-started-building-juice-4ocg

This post is about what came next.

Not just what Juice is, but what I’m actually trying to build with it.

⚠️ The Problem Isn’t Just Classes

After stepping back, I realized something:

The issue wasn’t just Tailwind-style class overload.

It was bigger than that.

Most UI systems today:

Push styling into long class strings
Mix structure, intent, and design into one place
Become harder to read as complexity increases
Don’t feel like they scale conceptually

You can make them work—but you’re constantly managing them.

And that’s where things started to feel off to me.

💡 What If UI Was More Declarative?

Instead of this:

<div class="flex items-center justify-between p-4 bg-white rounded-lg shadow-md">

What if you could express intent more directly?

<div row centered gap="1" padding="4rem" card>

Not just shorter—but more meaningful.

That’s the direction Juice is going.

🧃 The Core Idea Behind Juice

Juice is built around one simple idea:

UI should describe intent, not implementation.

Instead of:

Writing long class lists
Remembering utility combinations
Repeating patterns across files

You define:

Layout
Spacing
Surfaces
Behavior

Using attributes that map to a design system.

🧱 Attributes Over Classes

Classes are flexible, but they come with trade-offs:

No structure
Easy to overuse
Hard to standardize across teams

Attributes, on the other hand:

Encourage consistency
Create a natural design language
Are easier to read at a glance

Example:

<div grid="2" gap="4">
  <div card>A</div>
  <div card>B</div>
</div>

You immediately understand:

Layout: grid with 2 columns
Spacing: gap of 4
Surface: reusable card style

No mental decoding required.

🎯 Not Just Styling — A System

Juice isn’t just about styling elements.

It’s about creating a cohesive UI system that includes:

🎨 Design tokens (colors, spacing, typography)
🧩 Components (cards, nav, sections)
⚡ Interactions (animations, states)
📱 Responsiveness (built-in, not bolted on)

The goal is to make UI:

Faster to build
Easier to read
More consistent

⚡ Where This Is Going

Right now, Juice is still early.

But the direction is clear:

A fully expressive attribute-based UI system
Designed to work standalone or alongside other frameworks
Built to integrate directly into WebEngine

And eventually:

A system where developers and non-developers can both build interfaces without fighting the code.

🧠 What I’m Exploring Next

Some of the things I’m actively thinking through:

How far can attributes go before they become noisy?
How should responsiveness be handled without clutter?
What’s the right balance between flexibility and structure?
How can this integrate with things like WebGL and dynamic UI?

🚀 Why This Matters (To Me)

At the end of the day, this isn’t just about CSS.

It’s about reducing friction when building ideas.

Because when UI becomes easier to reason about:

You build faster
You experiment more
You ship more

And that’s the real goal.

🤝 Let’s Build This Together

This is still evolving, and I’m learning as I go.

If you’ve run into similar frustrations—or have thoughts on this approach—I’d love to hear them.

Repo here:
👉 https://github.com/citrusworx/webengine/tree/master/libraries/juice

Next up, I’ll probably dive deeper into:

How Juice handles responsiveness
Or how it compares directly to existing frameworks in real-world use

Appreciate you reading 🙏

I got tired of class-heavy UI code, so I started building Juice

Drew Marshall — Tue, 14 Apr 2026 22:34:31 +0000

At some point, my markup started feeling… heavy.

Not slow. Not broken. Just hard to look at.

At some point, it stopped feeling like I was writing UI…
and started feeling like I was managing class strings.

The Problem

Modern CSS tooling solves a lot of problems.

But it also introduces some friction—especially at scale.

Verbosity

You end up stacking utilities:

<div class="flex flex-col items-center justify-center h-screen bg-gradient-to-r from-purple-400 to-pink-500">

It works. It’s powerful. But it’s a lot to parse.

Readability

When everything is a class:

layout
spacing
color
behavior

…it all blends together.

You stop seeing intent and start reading implementation.

Scaling UI Systems

As projects grow, this turns into:

long, unreadable markup
repeated patterns everywhere
small changes requiring multiple class edits

It works—but it starts to feel messy.

The Idea

What if UI wasn’t driven by long class strings?

What if it looked more like this:

<div flex="col" height="full" grad="candy-grape" centered>

Instead of stacking utilities, each attribute describes intent directly:

flex="col" centered → layout
height="full" → sizing
grad="candy-grape" → styling

Example

Here’s a simple comparison.

Tailwind-style

<div class="flex flex-col items-center justify-center h-screen bg-gradient-to-r from-purple-400 to-pink-500">
  <h1 class="text-2xl font-bold text-white">Hello</h1>
  <button class="mt-4 px-4 py-2 bg-black text-white rounded-md">Click me</button>
</div>

Juice

<div flex="col" height="full" grad="candy-grape" centered>
  <h1 fontSize="xl" fontColor="white">Hello</h1>
  <button margin-top="4rem" padding="x-4 y-2" bgColor="black" fontColor="white" rounded="md">
    Click me
  </button>
</div>

The difference isn’t just shorter code.

Each attribute expresses intent directly, instead of stacking utilities together.

Interactions & Animations

This pattern extends beyond layout and styling.

<button hover="scale-up" motion="fade-in">
  Click me
</button>

Interactions and animations follow the same idea:

attributes describe behavior
not just appearance

What Juice Is

Juice is an attribute-based UI system.

It’s designed to make UI code more:

expressive
readable
scalable

Core Ideas

Layout via attributes
Styling via attributes
Animations via attributes
Works standalone or with frameworks
Optional JS control when needed

Why I Built It

I wasn’t trying to replace existing tools.

I was trying to solve a personal problem:

I wanted my UI code to feel as clean as my logic.

I like systems.
I like consistency.

And I didn’t like how styling started to feel like a wall of strings.

So I started experimenting with attributes.

That turned into patterns.
Then conventions.
Then a system.

Who This Is For

Juice is probably a good fit if you:

build apps or dashboards
use Tailwind (or similar) but feel the verbosity
care about readability as your project grows

It’s probably not for you if you prefer:

strict class-based systems
or fully abstracted component libraries

Current State

Juice is currently in alpha.

That means:

things will change
APIs may evolve
ideas are still being refined

But the core concept is solid enough to start sharing.

Try It / Feedback

This is still early, and I’m actively shaping it.

If you’ve ever felt the pain of class-heavy UI code, I’d love your feedback:

Does this feel clearer or just different?
Would you actually use this in a project?

Repo:
👉 Juice

This isn’t meant to replace everything.

It’s just another way to think about UI—and I’m curious if it clicks for anyone else the way it did for me.

📚 Reading With Intention as a Builder

Drew Marshall — Sun, 12 Apr 2026 12:52:10 +0000

Lately I’ve been trying to be more intentional about what I read—not just consuming information, but actually learning things I can apply while building.

Here’s the current list I’ve been working through:

✅ Finished

Zero to One
The Cold Start Problem
The Lean Startup

📖 In Progress / Up Next

High Output Management
Platform Revolution
Obviously Awesome
Redeeming Science
Financial Intelligence for Entrepreneurs

🧠 What I’m Starting to Notice

Even though these books come from different angles—startups, product, management, finance—they keep pointing to the same ideas:

Building something “cool” isn’t enough
Growth is designed, not accidental
Positioning determines whether people care
Simplicity and clarity win over complexity
And understanding business is just as important as writing code

⚙️ Applying This in Real Time

I’m not reading these passively—I’m trying to apply them across the things I’m building right now.

Whether that’s:

Thinking about distribution before development
Designing systems instead of one-off solutions
Or being more intentional about how ideas are positioned

The goal is simple:

Build things that actually work in the real world—not just in theory.

🤝 Always Learning

If you’ve read any of these, I’d love to hear what stuck with you—or what I should add next.

I’m always looking to sharpen both the technical and business side of building.

Build for Worth, Not Valuation (Part 1 of a Practical Builder Series)

Drew Marshall — Sat, 21 Feb 2026 20:00:00 +0000

Startup culture has a default scoreboard:

How much did you raise?
What’s your valuation?
How fast are you growing?

Those are valid metrics.

But they aren’t the only ones that matter — and they aren’t the most useful if you’re early and self-funded.

This series is about a different scoreboard.

Not anti-VC.
Not anti-growth.

Just practical.

Today’s topic:

Build for worth.

What “Worth” Means in Builder Terms

Worth is not branding.
Worth is not vision.
Worth is not “potential.”

Worth means:

Someone pays without convincing.
The product reduces real friction.
The system works without manual babysitting.
Revenue sustains infrastructure.
Growth doesn’t require external rescue.

Worth is testable this week.

Not in a pitch deck.
In production.

The First Shift: Revenue Is Feedback

Free users validate interest.

Paying users validate worth.

If someone won’t pay $5, they won’t pay $50 later. Pricing doesn’t magically unlock value — it reveals it.

Practical move you can apply today:

Add a paid tier earlier than feels comfortable.
Even if it’s small.
Even if it’s limited.
Even if only 3 people convert.

Those 3 are signal.

And signal is better than applause.

The Second Shift: Automate Before It’s Urgent

At 10 users, manual processes feel fine.

At 50, they feel annoying.
At 200, they break.

If you’re manually:

Creating accounts
Provisioning infrastructure
Sending invoices
Deploying environments
Running migrations
Onboarding users

You are building fragility.

Automation isn’t for scale.
It’s for stability.

Practical move:

Pick one repetitive task this week and eliminate it with:

A script
A webhook
A background job
A queue worker
A CI pipeline

Small automation compounds.

The Third Shift: Reduce Surface Area

Features feel productive.
Complexity feels impressive.

But complexity increases maintenance cost.

Before adding something, ask:

Does this reduce churn?
Does this remove friction?
Does this directly increase revenue?
Or does it just expand scope?

Surface area expands faster than revenue if you’re not careful.

And expanded surface area increases support load, bugs, and cognitive overhead.

Practical move:

Remove one feature this quarter.

Or delay it intentionally.

Durability grows when surface area shrinks.

The Fourth Shift: Design for 100 Customers First

Ask yourself:

If this had 100 paying customers tomorrow:

Would infrastructure hold?
Would support overwhelm you?
Would billing break?
Would deployment fail?
Would monitoring catch issues?

If the answer is “probably not,” then growth would hurt you.

Worth-driven building assumes growth will come — but prepares for it calmly.

The Fifth Shift: Make Funding Optional

This is the quiet power move.

If you must raise to survive, your decisions become reactive.

If you can survive without raising, funding becomes optional leverage.

Optionality changes:

Negotiation power
Stress levels
Timeline flexibility
Roadmap clarity

Worth creates optionality.

Optionality creates strategic calm.

A Practical Weekly Builder Checklist

If you want to apply this immediately, use this:

Each week, improve at least one of these:

Increase revenue signal
Decrease manual operations
Reduce feature surface area
Improve automation
Strengthen system reliability
Simplify onboarding
Improve retention

If you consistently move those levers, worth compounds.

Valuation may or may not follow.

But durability will.

What This Series Is About

This is Part 1 of a practical builder series.

Not theory.
Not startup drama.
Not fundraising strategy.

Just operational thinking for builders who want to create durable systems.

In Part 2, we’ll talk about:

Why Automation Is a Survival Strategy for Small Teams

Because most small startups don’t fail from lack of ideas.
They fail from operational drag.

—

If you’re building something right now, ask:

If I couldn’t raise money for this, how would I design it differently?

That answer will change your roadmap.

What Am I Doing?

Drew Marshall — Sun, 15 Feb 2026 20:17:57 +0000

What Am I Doing? (A Developer’s Mid-Journey Reality Check)

Lately I’ve been asking myself a question that feels simple but hits deeper the longer I sit with it:

What am I actually trying to accomplish?

Not:

what project I’m shipping
what language I’m using
what framework I’m learning

But the bigger question:

Why am I building all of this in the first place?

If you’re a developer, builder, or creator juggling multiple interests, this might sound familiar.

When Your Developer Journey Stops Being Linear

Tech culture often pushes specialization:

pick a stack
pick a niche
climb the ladder
repeat

But some of us don’t operate that way.

Personally, I’m:

building software systems
learning electronics and hardware
exploring self-hosted infrastructure
maintaining real-world equipment
working on creative projects and long-term business ideas

From the outside, that can look scattered.

From the inside, it feels like building capability.

Understanding systems end-to-end.
Reducing dependency where possible.
Creating instead of only consuming.

Still… eventually you pause and ask:

Am I building toward something — or just building?

The Hidden Driver: Proving Something

This is the uncomfortable part most developers don’t talk about.

Sometimes we start building because we want to prove:

we belong in tech
we’re capable
we’re not impostors
past doubts were wrong

That motivation works — for a while.

It pushes learning.
It builds momentum.
It fuels late-night debugging sessions.

But proof is an endless game.

There’s always:

another framework
another architecture
another comparison
another milestone

Eventually you have to ask:

Am I still building from curiosity — or from pressure?

The Question Every Builder Eventually Faces

At some point, a deeper question sneaks in:

Am I enough without the projects?

And here’s the uncomfortable truth:

Shipping more code doesn’t permanently answer that.

Neither does:

promotions
side projects
open source contributions
certifications
follower counts

A healthier question might be:

Am I aligned with the person I want to become?

That shifts the focus from output to direction.

Why Builders See Opportunity Everywhere

If you’re systems-minded, you probably notice this too:

Everything looks like something you could improve.

Apps.
Workflows.
Hardware.
Infrastructure.
Business models.

That’s entrepreneurial pattern recognition.

But it comes with a risk:

Feeling like you should pursue every idea.

I’m learning something important:

Not every good idea deserves immediate execution.

Capturing ideas preserves them.
Execution — not novelty — creates impact.

The Thread That Keeps Appearing

When I zoom out, there’s actually a consistent theme across everything I build:

Ownership. Autonomy. Creation.

Examples:

self-hosted tools instead of pure SaaS dependence
understanding full-stack systems instead of black boxes
building infrastructure instead of only using it
creating original work instead of chasing trends

That realization helped reduce the feeling of randomness.

It’s not scattered.

It’s integrated.

The Loneliness Part (Most Builders Feel This)

Big visions can feel isolating.

Not because others don’t care, but because:

most developers specialize
most companies optimize for short-term output
ecosystem building takes time

Often collaborators show up after progress becomes visible.

Not before.

That’s normal — even if it feels frustrating.

What I’m Realizing Right Now

I don’t think I have much left to prove anymore.

But I do have things I want to build.

That distinction matters.

Building to prove worth creates pressure.
Building with purpose creates sustainability.

And sustainability is underrated in developer culture.

So… What Am I Doing?

Right now?

I’m building intentionally.

Not for hype.
Not for comparison.
Not to chase every trend.

But to:

keep learning
maintain independence where possible
create useful tools
support creative expression
and document the journey honestly

Clarity isn’t always something you find before building.

Sometimes clarity emerges because you build.

And honestly?

That’s enough for me right now.

Daily Debug — Day 1: Blocks in Motion

Drew Marshall — Sun, 01 Jun 2025 01:36:17 +0000

✅ What I Got Done Today

📦 Completed 4 modules in Blender — continuing to build muscle memory with modeling tools and interface flow. Already feeling more confident navigating the workspace.
🎬 Started building a one-shot in Unreal Engine called The Overture Pact — early concept work, scene blocking, and thinking through tone and mechanics. Feels cinematic and story-driven.
🎮 Kicked off a mini-game in Godot called NumberFall — a simple, falling-number mechanic for now, but a great way to practice core Godot features and UI work.

🧠 What I Learned / Noticed

Working across three engines sounds chaotic, but it wasn’t—each served a different creative purpose:

Blender for design and visuals
Unreal for immersive storytelling
Godot for gameplay testing and prototyping

That’s the rhythm I want to cultivate: let each tool serve its unique purpose instead of trying to force a “one-size-fits-all” workflow.

🎯 Tomorrow’s Goals

Finish one more Blender module (possibly start texturing)
Flesh out player input in NumberFall
Document world/plot for The Overture Pact
Bonus: string swap on both guitars if time permits

💭 Reflection

Today felt modular in the best way. Not everything needs to be polished or final—what matters is that pieces are moving. As long as I keep shipping small things and logging what I learn, the bigger picture builds itself.

One mechanic. One asset. One idea at a time.

Daily Debug — Day 0: Why I’m Writing This

Drew Marshall — Sat, 31 May 2025 10:36:00 +0000

I’m building three companies from the ground up:

🎸 WINK Guitar — hand-crafted guitars, amps, pedals, and educational content
💻 Citrusworx — open source software & developer tools (Kiwi Engine, Juice, Nectarine, and more)
🎮 SubLime Studios — a creative game & entertainment studio blending storytelling, art, and design

Each of these companies represents a piece of me. They’re not side projects—they’re core to my mission: to create a career I don’t need to escape from. One rooted in creativity, ownership, and long-term impact.

But staying focused across such a wide scope is hard.

That’s why I’m starting this series. Daily Debug is my personal changelog. My ship log. My compass.

Each day, I’ll write:

✅ What I got done
🧠 What I learned (or struggled with)
🎯 What I plan for tomorrow
💭 A quick reflection

This isn’t for hype. It’s for momentum.

Because the only way to build something meaningful is to show up daily—even if it’s just one line of code or one decision made.

Let’s get to it.

Fighting Focus

Drew Marshall — Sat, 31 May 2025 10:32:29 +0000

Fighting Focus

by Drew Winkles

What is the one thing in your life that is non-negotiable?

For me, it's creating my own career.

I've worked for other companies and, truth be told, I fared well. Promotions came, responsibilities grew, and I adapted quickly. But there was always something missing. Sometimes it was that my full skill set wasn’t being used. Other times, there was no room to grow, or worse—hard salary caps that punished ambition. The reasons are plenty, but the feeling was consistent: I wanted more.

Not more money (although that’s part of it). More meaning. More control. More ability to build what I saw in my head without having to pitch it to someone whose vision was smaller than mine. That’s what led me to start Citrusworx, WINK Guitar, and SubLime Studios.

Three completely different fields—software, luthiery/audio gear, and games/entertainment—but all cut from the same cloth: creative engineering with freedom at the center.

I’ve always wanted to work for myself. Since I was a teenager. Since I realized I was good at many things, but didn’t want to silo those talents into one job description. Starting these ventures wasn’t just a business move—it was a promise to myself that I would stop waiting for permission.

But here’s the part no one glamorizes: finding the balance between these projects has been hard. Like, really hard. Some days it feels like I’m sprinting in three directions. I’m still figuring it out—how to prioritize without guilt, how to focus without abandoning ideas that still matter to me.

What I’ve come to understand is this: I can’t do it all. Not alone.

If I want Citrusworx to deliver real software, if I want WINK Guitar to be more than a cool brand name, and if I want SubLime to release actual games—I have to start outsourcing. I have to bring people in, delegate the stuff I don't need to micromanage, and trust that other skilled folks can help bring this vision to life.

And just as importantly, I’ve had to shift my mindset about learning.

I used to wait to be trained. To feel “ready.” I thought I needed to master everything in my little study corner before I launched anything real. But that’s not how the world works. The world is happening right now, and it's not waiting for me to feel prepared. It rewards those who learn by building, not those who build only once they’ve “learned enough.”

So I’m choosing to show up differently now. I’m carving out a day to really figure out my schedule—not just my to-do list, but a sustainable rhythm that respects my goals and my limits. One that includes shipping, writing, collaborating, and, yes, resting too.

Because I’m not just building products.

I’m building a life I believe in.

How do you deal with burnout?

Drew Marshall — Mon, 17 Feb 2025 23:20:44 +0000

I am a mega-creative person. I don't know how else to explain it but if you follow me long enough you will see what I am referring to. In that creative passion and pursuit I have created tons of projects for myself. The problem is that I want to complete all of them and keep them going, if at all possible.

I am sure there are other like-minded individuals who find themselves in this boat. How do you deal with burnout? Is it possible to come back from?

I ask because I am starting to feel the beginnings of it. I don't feel as passionate or motivated to complete them some days and then a spark of inspiration comes. Before I can maintain that momentum, it wisps away into the void.

I don't want to burn out.

I have taken a week or so off from these projects to kind of realign and enjoy some of my free time. Is that okay to do? It feels wrong.

🌎 Building an Empire—One Creative Venture at a Time

Drew Marshall — Sun, 09 Feb 2025 14:51:56 +0000

Not everyone is chasing quick riches. Some of us are here because we believe in the work. If an idea is worth its weight, efforts will be rewarded, but an idea alone isn’t enough—it doesn’t justify a lack of work.

This is about creating, innovating, and serving people, not just making money. Breaking even is a win if it means making an impact.

🏗️ What Empire Am I Building?

An empire that shares its wealth. An ecosystem of creative ventures—each carefully researched, coordinated, and built with purpose.

I’m not throwing spaghetti at the wall to see what sticks. These are intentional ventures, all connected by a tech-driven foundation.

💡 What Are My Ideas?

Everything I’m working on has a tech aspect, but they span across different industries and passions.

🖥️ Citrusworx – Open Source Software

🚀 Building software that’s accessible, ethical, and useful for developers and businesses alike.

🎮 SubLime Game Studios – Game Dev Studio

🎨 Creating interactive experiences that entertain, challenge, and inspire.

🛒 eCommerce Ventures – Selling Things That Matter

☕ Coffee – Because developers and creatives run on it.
👕 Apparel – Unique, expressive designs for passionate people.
🎮 Gaming Accessories – Because details matter when you’re in the zone.
🖥️ Themes & Plugins for:
- HTML / React / TypeScript
- PHP / Rust / Tauri
- WordPress / KiwiPress / Echo

🌐 Network of Things (NoT) Devices

💡 A safer alternative to IoT with room for true innovation.

🎸 WINK Guitar & Beryl Audio (Future Dream Endeavor)

🎶 A passion project—building tools for musicians, shaping sound, and blending tech with art.

📍 Starting From the Bottom

Right now, I’m a full-time student with a part-time job, working on these ventures in phases.

🔹 Open source projects? Jump in.

🔹 Game dev? Let’s jam.

🔹 New ideas? Let’s talk.

This isn’t a solo mission. I want to share this experience, build alongside others, and create things that matter.

🚀 Want to Follow the Journey?

If any of this resonates with you—let’s connect. Whether it’s coding, gaming, eCommerce, or music, there’s room for more creators here.

💬 Drop a comment. Let’s talk.

A Thank You to the Mentors Who Helped Shape My Learning Journey

Drew Marshall — Sun, 09 Feb 2025 11:46:36 +0000

For the longest time, I thought school was out of the question. Life threw one unfortunate circumstance after another my way, and the idea of returning to formal education felt impossible. But that never stopped me from learning.

Instead, I found another path—one paved by incredible educators and creators who shared their knowledge with the world. Through their courses, books, and streams, I navigated the world of full-stack development and React. This post is my way of saying:

Thank you.

Brad Traversy – Teaching the Core of JavaScript

JavaScript was my gateway into serious development, and Brad Traversy’s teaching made it click. His clear, no-nonsense approach to Vanilla JavaScript helped me build a solid foundation before diving into frameworks and libraries. The way he breaks down complex topics into something digestible is a gift, and I’m grateful for how much his content has shaped my understanding.

Brad Traversy

Maximilian Schwarzmüller – Guiding Me Through React and Beyond

When I stepped into the world of React, React Native, TypeScript, and Flutter, Maximilian Schwarzmüller was there to guide me. His courses weren’t just about coding—they were about understanding the why behind the tech. His structured yet approachable teaching style made these complex topics feel manageable, and I wouldn’t be where I am today without his lessons.

Academind

PirateSoftware – For the Morale Boost & Like-Minded Energy

Sometimes, learning isn’t just about the code—it’s about the mindset. PirateSoftware has been a huge morale booster, reminding me why I love tech and why pushing forward matters. Seeing someone so passionate about building, learning, and sharing knowledge has been inspiring. It’s good to know there are like-minded people out there who just get it.

PirateSoftware Twitch

Looking Ahead

Now, as I prepare to finally complete my Computer Science degree, I carry these lessons with me. School may have felt out of reach for a long time, but the knowledge I’ve gained from these educators has been invaluable.

So, to Brad, Max, and Thor—thank you for making learning accessible, engaging, and inspiring.

And to anyone reading this: **Who has helped you on your learning journey?

** Whether it’s a course, a book, a mentor, or even a streamer—drop a thank you in the comments! Let’s show appreciation to the people who help shape us. 🚀

What Is A Creative Engineer?

Drew Marshall — Sun, 09 Feb 2025 11:34:47 +0000

Is "Creative Engineer" a widely recognized term? Probably not.

Did I come up with it myself one day? Absolutely.

Could I Google it to see if others are using it? Sure.

Am I going to? Nope.

Because I don’t define myself by search engine results.

I define myself by what I do.

So... What Is a Creative Engineer?

A creative engineer has no limits. If they can conceive it, they can build it. They are designers, developers, architects, and problem-solvers—bridging creativity and technical expertise to bring ideas to life.

They touch every aspect of a product’s lifecycle:

The design that makes it intuitive.
The code that makes it function.
The infrastructure that makes it scalable.
The user experience that makes it valuable.

A creative engineer isn’t just a specialist in one area—they see the full picture.

Why This Matters to Me

I’ve always been fascinated by technology, but I never wanted to be confined to just one role. I don’t want to just write backend logic and never think about design. I don’t want to only design interfaces and never understand how the code works. I want to create.

That’s why I’m currently on a mission to master multiple technologies—from HTML and JavaScript to C++ and AWS Cloud. I want to be able to take an idea and see it through from start to finish, whether it's software, hardware, or something entirely new.

Entrepreneurial? Yes, but With Actual Skills.

You could say a creative engineer is like an entrepreneur—someone who drives ideas forward. But here’s the difference:

They don’t just fund the vision. They build it.

Some entrepreneurs leverage finances or connections to bring an idea to life. That’s great, but let’s be real—having money isn’t a skill.

A creative engineer? They don’t just see the vision. They have the skills to make it happen.

Are You a Creative Engineer Too?

If this resonates with you—if you love the idea of designing, coding, and building without limits—I want to hear from you!

🔹 Do you consider yourself a creative engineer?

🔹 What skills are you working on right now to expand your abilities?

🔹 Have you ever built something entirely on your own from idea to launch?

Let’s connect and build awesome things together. 🚀