DEV Community: Claudia Nadalin

Why We Don't Tell You What to Build (FrontendCheck)

Claudia Nadalin — Sun, 04 Jan 2026 10:46:55 +0000

The following is a blog post from FrontendCheck.com, a platform that teaches devs how to build unique SaaS with enterprise architecture. Your patterns. Your portfolio. Your thing.

Every coding tutorial tells you exactly what to build. A todo app. A weather dashboard. A Twitter clone. We do something different—we teach the architecture and let you decide what product to create. Here's the philosophy behind that choice.

The Problem with Prescribed Projects

Traditional tutorials have a fundamental tension: they need to teach technical concepts, but they also need to tell you what to build. The result is millions of developers with identical portfolios.

How many todo apps exist in the world? How many weather dashboards? How many Twitter clones that look exactly like the tutorial they came from?

When everyone builds the same thing, several problems emerge:

Your portfolio doesn't stand out. Hiring managers have seen the same projects hundreds of times.
You don't practice making product decisions. Real work requires deciding what to build, not just how.
Motivation suffers. Building something you don't care about is a slog.
You can't explain your work with passion. Try getting excited about todo app #38 in an interview.

Separating Architecture from Product

Here's the insight that changed everything for us: the architectural patterns are the same regardless of what you're building.

Multi-tenant data isolation works the same way whether you're building a task manager, a CRM, or a cat fashion store. Role-based permissions follow the same patterns whether it's for a notes app or an ex-tracking relationship retrospective tool. Theming systems, internationalization, real-time updates—the architecture is consistent.

So why force everyone to build the same product?

We separated the concerns. We teach the architecture—the patterns that transfer to any product. You decide what product to apply them to.

Domain-Adaptive Learning

We call this approach domain-adaptive learning. Each challenge teaches specific architectural patterns, but you choose the domain that interests you.

Want to build a task manager? Great—maybe it becomes ChoreQuest, a gamified household chore tracker. Or ADHD Brain Dump, a neurodivergent-friendly task capture tool. The domain provides the vocabulary and data structures. You decide the personality.

Prefer a CRM? It could become Meowdrobe, managing cat fashion influencer relationships. Or Band Manager, tracking touring musician contacts. Same architectural patterns, completely different products.

Two people completing the same challenge will have entirely different portfolio pieces. Both learned identical skills. Neither can be accused of just copying a tutorial.

Why This Matters for Your Career

When you interview for a frontend role, you'll be asked about projects you've built. The difference between these two answers is significant:

"I built a todo app from a tutorial. It has CRUD operations."

versus:

"I built ChoreQuest, a gamified household task manager. It uses multi-tenant architecture so families can have separate workspaces, role-based permissions so parents and kids have different capabilities, and a dynamic theming system so each family can customize their experience. I chose the gamification angle because I wanted to solve the problem of motivating kids to do chores."

The second answer demonstrates the same technical skills but shows something more: product thinking, creativity, and genuine investment in the problem being solved.

Creative Ownership Creates Better Learning

There's a pedagogical reason for this approach too. When you care about what you're building, you learn better.

Motivation isn't just nice to have—it's essential for deep learning. When you're building something you actually want to exist, you push through the hard parts. You go beyond the minimum requirements. You think about edge cases because they matter to your vision, not because a tutorial told you to.

The architecture we teach is genuinely challenging. Multi-tenant data isolation, permission systems, internationalization—these aren't simple topics. Having a product you care about makes the challenge worth tackling.

The Weird App Advantage

We encourage weird app ideas. Not because weird is better, but because weird is memorable.

A cat fashion store CRM sticks in people's minds. A meditation app for programmers called /dev/zen makes people smile. An ex-tracking relationship retrospective tool makes people ask questions.

Memorable projects get discussed. They get shared. They make interviewers curious. They demonstrate personality.

And here's the thing: the technical patterns are exactly the same as "serious" apps. A cat fashion store CRM and a real enterprise CRM use identical multi-tenant architecture. The whimsy doesn't diminish the technical achievement—it just makes it more interesting to talk about.

How It Works in Practice

When you start a FrontendCheck challenge, you choose from available domains—task manager, CRM, notes app, inventory, and more. Each domain comes with appropriate vocabulary, data structures, and example applications.

Then you receive stakeholder emails introducing requirements. These requirements teach architectural patterns: "We need to support multiple organizations" teaches multi-tenancy. "Different user roles need different permissions" teaches RBAC. The patterns are consistent; the product context is yours.

You build your app using these patterns. You name it. You style it. You deploy it. When you're done, you have a unique portfolio piece that demonstrates enterprise-level skills in a package that's entirely your own.

Architecture Transfers, Products Don't

The skills you learn are the same regardless of what you build. Multi-tenant architecture works identically in a task manager and a CRM. Permission systems follow the same patterns whether you're managing chores or managing inventory.

But the product? That's yours. That's what makes your portfolio unique. That's what you'll talk about in interviews with genuine enthusiasm.

We don't tell you what to build because we don't need to. The architecture is what matters, and that we teach thoroughly. The product is what makes it yours—and that should come from you.

Key takeaway: We teach enterprise architecture patterns. You decide what product to build with them. Same skills, unique portfolio. That's the FrontendCheck philosophy.

If you'd like to build your own unique SaaS using enterprise frontend techniques, then start the free challenge over at FrontendCheck.com.

I Built a Module System for a Language That Doesn't Have One

Claudia Nadalin — Sat, 27 Dec 2025 21:26:11 +0000

You know what's funny about PineScript? It's 2025 and we're writing trading indicators like it's 1995. One file. Everything global. No modules. No imports. Just you, your code, and the slow descent into madness.

I'd been putting up with this for a while. I had a fairly complex indicator that used code I'd split across multiple TradingView libraries. Seemed like the right thing to do at the time. Separate concerns. Keep things clean. Very professional.

Then I needed to change one function.

The Workflow From Hell

Here's what updating a library function looked like:

Edit the code locally
Push to git
Copy-paste into TradingView's editor
Republish the library
Note the new version number
Open my indicator script
Update the import statement with the new version
Save that
Push that to git
Copy-paste into TradingView's editor
Save again

And that's for ONE library. I had five.

You ever see that Seinfeld episode where George tries to do the opposite of every instinct he has? That's what this workflow felt like, except I wasn't getting a job with the Yankees at the end of it. I was just trying to fix a bug.

There had to be another way.

Surely Someone's Solved This

I started researching. Googled things like "PineScript bundler", "PineScript multiple files", "PineScript module system".

I found:

VS Code extensions for syntax highlighting (cool, but not what I need)
PyneCore/PyneSys, which transpile PineScript to Python for running backtests locally (interesting, but different problem)
A lot of forum posts from people with the same frustration and no solutions

What I didn't find was a bundler. Nobody had built the thing I wanted.

But even before searching, I knew why this was hard. I knew what any solution would require. And it wasn't pretty.

Why This Is Actually Hard

JavaScript has something called scope. When Webpack bundles your code, it can wrap each module in a function and they're isolated from each other:

var __module_1__ = (function () {
  function double(x) {
    return x * 2;
  }
  return { double };
})();

var __module_2__ = (function () {
  function double(x) {
    return x + 100;
  } // No collision - different scope
  return { double };
})();

Two functions named double, no problem. They live in different scopes. They can't see each other. Webpack leverages this to keep modules isolated.

PineScript doesn't have this.

There are no closures. No way to create isolated scopes. Everything is basically global. If you define double in one file and double in another file, then smash those files together, you've got a collision. One overwrites the other. Your code breaks.

So any PineScript bundler would need to rename things. Take the double function from utils/math.pine and rename it to something like __utils_math__double. Do the same for every export from every file. Update all the references. No collisions.

I knew this was the path before I wrote a single line of code. The question was: how do you actually rename things in code reliably?

The Find/Replace Trap

My first instinct was simple: just use find/replace. Find double, replace with __utils_math__double. Done.

Here's why that falls apart immediately. Imagine this code:

double(x) =>
    x * 2

myLabel = "Call double() for twice the value"
doubleCheck = true
plot(double(close), title="double")

You want to rename the double function to __utils_math__double.

With find/replace, you'd get:

__utils_math__double(x) =>
    x * 2

myLabel = "Call __utils_math__double() for twice the value"  // Broken - changed string content
__utils_math__doubleCheck = true                              // Broken - renamed wrong variable
plot(__utils_math__double(close), title="__utils_math__double")   // Broken - changed string content

You've corrupted string literals and renamed a completely unrelated variable that happened to start with "double".

Find/replace sees code as a flat string of characters. It has no idea that "double" inside quotes is a string, not a function reference. It can't tell that doubleCheck is a different identifier. It just sees the letters d-o-u-b-l-e and does its thing.

I needed a way to understand the structure of the code. To know that this double is a function definition, that double is a function call, and that "double" is just text inside a string that should be left alone.

This is where I got stuck. Building something that truly understands PineScript's structure would take months. Parsing is hard. PineScript has weird indentation rules, line continuation, type inference, all sorts of quirks.

Then I found pynescript.

The Missing Piece

pynescript is a Python library that parses PineScript into something called an Abstract Syntax Tree (AST), and can unparse it back into PineScript.

If "Abstract Syntax Tree" sounds intimidating, don't worry. It's actually a simple concept. An AST is basically the DOM, but for code instead of HTML.

When your browser gets HTML, it doesn't keep it as a string. It parses it into a tree structure where each node knows what it is. A <div>. A <p>. A text node. You can manipulate these nodes programmatically - add classes, change text, move things around - without doing string manipulation on raw HTML.

An AST does the same thing for code. When you parse this:

double(x) =>
    x * 2

myLabel = "Call double()"

You get a tree like:

Script
├── FunctionDefinition
│   ├── name: "double"           ← I'm a function definition
│   ├── parameters: ["x"]
│   └── body: BinaryOp(x * 2)
│
└── Assignment
    ├── target: "myLabel"
    └── value: StringLiteral     ← I'm a string, leave me alone
        └── "Call double()"

Now renaming becomes surgical. You say: "Find all nodes of type FunctionDefinition where name equals double. Rename those. Find all nodes of type FunctionCall where the function is double. Rename those too. Leave StringLiteral nodes alone."

The string content is untouched because it's a StringLiteral node, not a FunctionCall node. doubleCheck is untouched because it's a completely different identifier node. The structure tells you what's what.

pynescript had already done the hard work of parsing PineScript correctly. Months of work with ANTLR (a serious parser generator). I could just pip install pynescript and get access to that tree.

I had my strategy (rename with prefixes), and now I had my tool (AST manipulation via pynescript). Time to see if it actually worked.

The Spike

Before committing to building a full tool, I wanted to prove the concept. Take two PineScript files, parse them, rename stuff in the AST, merge them, unparse, see if TradingView accepts the output.

I created two tiny files:

math_utils.pine:

//@version=5
// @export double

double(x) =>
    x * 2

main.pine:

//@version=5
// @import { double } from "./math_utils.pine"

indicator("Test", overlay=true)

result = double(close)
plot(result)

Then wrote some Python to:

Parse both files with pynescript
Find the function definition for double in the AST
Rename it to __math_utils__double
Find references to double in main.pine's AST
Update them to __math_utils__double
Merge and unparse

I ran it. Out came:

//@version=5
indicator("Test", overlay=true)

__math_utils__double(x) =>
    x * 2

result = __math_utils__double(close)
plot(result)

I pasted it into TradingView.

It worked.

I sat there for a second, genuinely surprised. Not because it was magic, but because I'd expected to hit some weird edge case or parser limitation that would kill the whole idea. But no. It just... worked.

Building the Real Thing

With the spike working, I built out the full tool:

A CLI (pinecone build, pinecone build --watch)
Config file support
Proper dependency graph construction
Topological sorting (so dependencies come before the code that uses them)
Error messages that point to your original files, not the bundled output
A --copy flag that puts the output straight into your clipboard

The module syntax uses comments so that unbundled code doesn't break if you accidentally paste it into TradingView:

// @import { customRsi } from "./indicators/rsi.pine"
// @export myFunction

TradingView's parser just sees these as comments and ignores them. PineCone sees them as directives.

The prefix strategy uses the file path. src/utils/math.pine becomes __utils_math__. Every exported function and variable from that file gets that prefix. Every reference to those exports gets updated.

It's not elegant. Your bundled output has ugly names like __indicators_rsi__customRsi. But it works. TradingView accepts it. There are no collisions. And you never have to look at the bundled output anyway - it's just an intermediate artifact, like compiled code.

What Did I Actually Build?

I've been calling it "Webpack for PineScript" but that's not quite right. Webpack does a lot of stuff: code splitting, lazy loading, tree shaking, hot module replacement.

PineCone does one thing: it lets you write PineScript across multiple files with a module system, and compiles it down to a single file TradingView can understand.

It's a module system and bundler for a language that has neither.

PineCone doesn't add features to PineScript. It doesn't make your indicators faster. It doesn't connect to your broker. It just lets you organize your code like a normal human being in 2025.

And honestly? That's enough. That's the thing I needed.

The Takeaway

If you're working with a language that's missing something fundamental, you might not be stuck. Look for parsers. Look for AST tools. If someone's already done the work of understanding the language's structure, you can build on top of that.

pynescript didn't solve my problem directly. It's a parser, not a bundler. But it solved the hard part - correctly parsing PineScript - and let me focus on the part I actually cared about: the module system.

Anyway, Pinecone is open source. If you're a PineScript developer who's ever felt the pain of managing multiple libraries, give it a try. And if you've got ideas for making it better, I'm all ears.

Serenity now.

Pinecone is available here. Built with pynescript, which you should also check out if you're doing anything programmatic with PineScript.

Claudia is a Frontend Developer. You can find more of her work here.