What Do You Build With After Scratch? — No-Code and Low-Code as Implementation Options [Technovate Thinking ⑧ Day4 Part2]

This is Part 8 of my 12-part series documenting what I learned in the “Technovate Thinking” course at business school.

The first half of Session 4 was the report submission (covered in the previous article), and the second half took a completely different tone. The theme was “Implementation Methods in the Technovate Thinking Problem-Solving Process” — a session on learning various implementation approaches, starting with no-code.

We’d been training our logical thinking through Scratch. So when you actually want to build something for business, what do you use? This question was a crucial turning point as we entered the second half of Technovate Thinking.

Scratch Taught Us “How to Think” — Now It’s Time for “How to Build”

The reason we’d been using Scratch up to this point was to experience the “way of thinking” behind programming. Variables, lists, conditional branching, loops, flowcharts — we hands-on learned the fundamental building blocks of logical design.

The beauty of Scratch is that you don’t have to worry about syntax errors. Since it works just by combining blocks, you can “focus entirely on the logic.” No environment setup needed. A browser is all you need. For people with no programming experience, it was an ideal entry tool.

However, when you try to build something for actual business use, Scratch has its limits. Database connections, web API calls, user authentication — the elements needed for business applications can’t be achieved with Scratch. “So what should I use to implement things?” — that was the question the second half of Session 4 set out to answer.

The Range of Implementation Options Is Wider Than You’d Think

In class, implementation methods were presented across several layers.

No-Code Tools: Building Apps Without Writing Code

A family of tools that let you build applications and workflows through visual interfaces alone, with no programming required. Representative examples include AppSheet, Bubble, and Adalo.

AppSheet can auto-generate a mobile app using a Google Spreadsheet as the data source. For apps centered on “entering, viewing, and updating data” — like inventory management or daily reports — you can have something functional within hours. Bubble can build more complex web applications, with visual tools for user authentication and workflows. Adalo specializes in mobile apps with a high degree of UI customization freedom.

The strength of no-code is overwhelming speed. Having a working prototype the day after you come up with an idea — that really happens. The weakness, however, is that these tools struggle with “processing the tool wasn’t designed for.” When you try to incorporate complex calculation logic or custom algorithms, no-code reaches its limits.

Low-Code Tools: Writing Code Only When Needed

An approach that sits between no-code and full programming — you build visually by default and write code only when necessary. Microsoft Power Apps and OutSystems are leading examples.

The advantage of low-code is that it maintains the simplicity of no-code while allowing customization where you need it. For example, you build the basic screens in Power Apps and write specific input validations using Power Fx expressions (similar to Excel formulas). More flexible than no-code, less development effort than full programming.

In enterprise settings, low-code is commonly used for integration with existing business systems. If an organization already uses Microsoft 365, Power Apps can quickly build apps that integrate with SharePoint and Teams. This “affinity with the existing environment” is a major strength of low-code.

API Integration and Automation Tools: Connecting Existing Services

Automation tools represented by Zapier and Make (formerly Integromat). Rather than “building” a new app, the idea is to create value by “connecting” existing services together.

For example: “When an email with a specific subject arrives in Gmail, save the attachment to Google Drive and send a notification to Slack.” What used to be done manually can be automated with no code.

What makes this approach interesting is the combinatorial thinking it requires. “Which services connected to which other services would make which workflows easier?” — thinking through this question is Technovate Thinking in action. You don’t need to know the underlying technology, but you do need the ability to envision “what can be automated.”

Full Programming: Complete Freedom — at a Cost

Python, JavaScript, Swift — building completely from scratch using programming languages. Freedom is at its maximum: complex processing that no-code can’t handle, AI integration, custom algorithm implementation — all possible.

However, the learning curve and development effort are orders of magnitude greater. Even a simple CRUD app (Create, Read, Update, Delete) that would take hours in no-code can take days with full programming.

Full programming becomes necessary in scenarios requiring advanced customization, services with massive user bases, or situations with strict security requirements. The key understanding isn’t “everything should be built with code” but rather “there are situations where only code can solve the problem.”

Decision Criteria: How Do You Decide “What to Build With”?

The important point here is that these are options, not a ranking. “No-code is for beginners, programming is for advanced users” is wrong. The right answer is choosing the most efficient tool for the problem at hand — each tool has its “sweet spot” and its “pain points.”

I felt there are four main criteria to consider.

First: problem complexity. For a simple data entry and lookup app, no-code is sufficient. If complex business logic is involved, you’ll need at least low-code. If a custom algorithm is the core of the solution, full programming is the way to go.

Second: speed. If you need a prototype by next week, no-code is the only option. If you have six months to build something serious, full programming enters the picture. In business, “shipping something 80% right quickly and getting feedback” is often more valuable than “delivering perfection slowly.”

Third: extensibility and scalability. For an internal team tool used by 10 people, no-code can handle it fine. For a service with tens of thousands of users, full programming is often more appropriate from both performance and security standpoints.

Fourth: the team’s skill set. If there are no engineers on the team, using no-code lets the team handle process improvements independently. If you have an engineering team, full programming might yield better results by fully leveraging their technical capabilities.

“Humans Design the Logic, Tools Handle the Implementation” — A Deeper Understanding

The core philosophy of Technovate Thinking is: “Computers handle mass data processing and repetitive tasks; humans handle logical design.” I’d experienced the first half of this through earlier sessions, but hearing about no-code tools gave me my first real sense of the second half.

With no-code tools, you can build apps without knowing the details of programming. But “what to process and with what logic” still needs to be designed by a human. What the tool takes off your plate is the effort of implementation — not the thinking behind the design.

Consider building an inventory management app with AppSheet. The tool auto-generates the screen layout. But the business rule “auto-order when stock drops below a threshold” has to be defined by a human. What threshold? Which supplier? How to handle exceptions? These decisions are beyond the tool’s capability.

The experience of drawing flowcharts in Scratch, designing conditional branches, and thinking through data flows becomes the “design foundation” when using no-code tools — that’s the message I took away from the second half of Session 4.

An IT Veteran’s Take: Common Ground and Temperature Differences in Tool Selection

The topic of tool selection was very familiar territory for someone with my IT infrastructure background.

Common Ground: The Decision Framework Has the Same Structure

In infrastructure design, there are analogous decisions: “cloud or on-premises?” “managed service or self-built?” The factors you weigh are cost, speed, customizability, and operational burden. The decision criteria for no-code vs. programming have fundamentally the same structure.

For instance, a cloud “managed database” is, in a sense, the no-code of infrastructure. The cloud vendor handles DB tuning and backups for you, but in exchange, fine-grained customization is restricted. The trade-off between convenience and flexibility — this structure is identical to the no-code vs. programming relationship.

Temperature Difference: What Gets Prioritized Differs

That said, infrastructure decisions tend to prioritize “stability and security” above all. If systems go down, the entire business grinds to a halt, and security incidents are irreversible. So choosing “proven, battle-tested technology” is often treated as the right call.

In application development, on the other hand, “speed and user value” tend to take priority. To keep pace with market changes, speed is demanded over perfection. Get user feedback fast and iterate.

I realized this temperature difference is worth keeping in mind when working across departments. The infrastructure team says “we haven’t validated this enough yet,” while the app team says “if we don’t ship now, we’ll be too late” — this conflict isn’t about either side being wrong. They’re prioritizing different values. Someone who understands both perspectives can bridge the gap between teams.

Where No-Code “Wins” and Where It “Struggles”

Combining what I learned in class with my own experience, I organized the scenarios where no-code particularly shines and where it falls short.

Where no-code wins:

• Internal process improvement tools (daily reports, inventory management, approval workflows)
• Prototypes and MVPs (when you want to validate in the market with minimal features)
• Apps centered on data entry and lookup
• When engineering resources are limited and business teams want to be self-sufficient

Where no-code struggles:

• Services where custom algorithms or complex calculations are the core
• Large-scale B2C services with massive user bases (performance and scalability concerns)
• Financial or healthcare systems with stringent security requirements
• Scenarios requiring complex integration with multiple other systems

The crucial thing is not to force no-code in scenarios where it struggles. Precisely because you understand a tool’s limitations, you can make the right choice. And the foundation for that understanding is the “programming way of thinking” cultivated through Scratch.

What the “Democratization of Development” Brings

The spread of no-code and low-code is often called the “democratization of development.” App development, once the exclusive domain of engineers, is now accessible to people in business functions.

I view this trend positively. The people who understand a business problem best are those who deal with it every day. If the person who knows the problem can build their own solution, the communication cost of “translating requirements for engineers” disappears entirely.

However, democratization comes with risks. Governance is the issue. When departments independently build their own apps, data consistency can break down and security holes can emerge. Creating an environment where people are free to build while maintaining overall order — that’s the challenge organizations face when adopting no-code at scale.

This is the same pattern as the “shadow IT” problem that emerged during cloud adoption. People start using tools on their own because they’re convenient, and IT departments lose visibility. Tool democratization isn’t just a technology story — it’s an organizational management story as well.

The Scratch Experience as a “Design Foundation” — Confirmed

What I felt most strongly through this session was that the hands-on Scratch experience cultivated the “evaluative eye” for assessing any implementation approach.

When looking at a no-code tool’s interface, I can read the structure: “This is where a conditional branch is being set,” “This workflow is a loop.” When looking at an API integration tool’s settings screen, I can parse it: “This trigger is the input, this action is the output, and there’s a filter condition in between.”

This perspective is possible precisely because I assembled blocks in Scratch, drew flowcharts, and experienced firsthand how variables and lists behave. Knowing the “way of thinking” behind programming is what enables you to accurately evaluate tools beyond programming itself.

Conversely, if you use no-code tools without understanding programming concepts, you risk ending up in a state of “it works, but I don’t know why it works.” In that state, you can’t troubleshoot problems, and you can’t identify the tool’s limitations.

Lesson: “Choosing What to Build With” Is a Leadership Skill

If I had to summarize the takeaway from the second half of Session 4 in one line, it’s this: What’s expected of a business leader isn’t “the ability to write all the code yourself” but “the ability to appropriately choose what to build with.”

What that requires is understanding the fundamental concepts of programming (variables, conditional branching, loops, data structures). With that understanding, you can look at a no-code tool’s interface and know “what’s happening here.” In conversations with engineers, you can intuitively gauge “how technically challenging is that?”

And one more crucial point: don’t view technology choices as a hierarchy. The assumption that “no-code is for beginners” and “programming is for experts” should be discarded. Professional engineers choose no-code too. Not because they lack ability, but because they judged that no-code was the optimal solution for that particular scenario.

All the hands-on Scratch work came together here. Having “experienced” programming is precisely what enables you to properly evaluate non-programming alternatives. This, I believe, is exactly the image of a leader who “commands technology” that Technovate Thinking aims to develop.

Next Up: Building My Own AI Coach App

The pre-work for Session 5 was “implement an application that’s useful for your business or daily life, using whatever tools you choose.” I’ll write next time about how I combined a no-code tool with an AI API to actually build my own personal “AI Coach” app. It was time to put the “power to choose what to build with” that I learned this session into practice.

Books Referenced in This Article