Why 'Using Less Resource and Achieve Big Time' Is More Than a Catchphrase

I've been saying this for years: "Using less resource and achieve big time."

It sounds like a slogan. Something motivational, printed on a poster next to a picture of a mountain. But it's not philosophy as decoration. It's philosophy as filter. It's shaped every significant decision I've made in 15 years, and every time I've ignored it, I've paid a price.

The core idea is this: Resource constraints aren't obstacles to work around. They're filters that force you toward better solutions.

When money is tight, complexity becomes expensive. When time is limited, every hour matters. When you don't have the luxury of "we'll just throw more infrastructure at this," you're forced to build something that actually works.

Most engineering problems can be solved three ways: the expensive way, the moderately expensive way, and the simple way that works better than both.

Nobody finds the simple way on their first try. You find it when you have no choice.

The Pattern Across 15 Years

Let me show you what I mean with four specific examples, separated by time and domain, all following the exact same pattern.

Example 1: 2008 - Game Automation (Age 18)

The constraint: No capital. I had maybe SGD 200 to my name.

The problem: Game economies generated value through repetitive resource farming. Manual farming took 4-6 hours daily and generated SGD 50-80. I needed better ROI.

Why expensive wouldn't work: Professional botting tools existed. They cost money. Monthly subscriptions. Feature-rich, complex, maintained by someone else. And I had exactly zero dollars to spend.

What I built instead: Basic Python scripts and AutoIt. No license costs. No monthly fees. Took me three weeks to learn enough scripting to build the first bot, another four weeks to refine it to not get caught.

The expensive solution: Pay for professional bot software. The simple solution: Teach myself to code and build exactly what I needed.

The result: Over three years, that SGD 0 investment generated over SGD 70K. The expensive tool would have cost me SGD 30/month (SGD 1,080 over three years), cutting my profit significantly. More importantly, I would have learned nothing.

What I learned: If you can't afford the expensive solution, you learn to code. And once you can code, expensive solutions look silly.

Example 2: 2020 - COVID Supply Chain Pivot (Age 28)

The constraint: The family-run electronics trading enterprise faced supply chain collapse. Limited capital. Uncertain timeline. Business survival at stake.

The problem: Suppliers cut off. Distribution channels disrupted. Revenue collapsing. We had maybe SGD 50K working capital.

Why expensive wouldn't work: Crisis consultants wanted SGD 30K+ retainers. New suppliers required factory visits. Expanding distribution meant hiring salespeople and opening new locations. We didn't have the budget for any of it.

What I did instead: Mapped existing customers and suppliers. Contacted alternative suppliers directly (email + phone, zero travel). Built e-commerce infrastructure using existing tools (Shopify + n8n + APIs we already knew). Restructured the existing team to handle online fulfillment instead of traditional distribution.

The expensive solution: Hire crisis consultants, invest in new infrastructure, hire salespeople. The simple solution: Use existing people and tools differently.

The result: Generated SGD 500K in additional revenue over six months. Bootstrap capital: SGD 15K in tools and platform fees. Return: 3,300%.

The consultants offering expensive solutions would have taken their cut, recommended we hire more people, and built systems we'd still be paying for. Instead, I built systems that anyone on the team could maintain.

What I learned: Crisis doesn't mean you need expensive solutions. It means you need clear thinking about what you already have.

Example 3: 2022 - RMA Automation at a global medical aesthetics and technology company (Age 30)

The constraint: No IT budget. Process was broken across APAC. My director asked if I could improve it.

The problem: RMA (returns management) complaints came in via email. Each one required manual data extraction, classification, and routing to different teams. Eight manual touchpoints per complaint. Each took 5-8 minutes. We processed 40-50 complaints daily.

Why expensive wouldn't work: Proper RMA software costs SGD 50K+/year. IT department would need 3 months to evaluate, procure, and implement. Still wouldn't be customizable for our specific workflow.

What I built instead: Open-source n8n automation running on infrastructure I already managed. JavaScript patterns to parse incoming email. Decision logic to classify complaints automatically. Integrations to the systems we actually used (no middle-layer software). Took me about 40 hours total.

The expensive solution: Buy enterprise RMA software (SGD 50K+/year, 3-month implementation, requires ongoing vendor management). The simple solution: Automate the workflow with tools I already knew (0 licensing cost, 40 hours one-time effort, 0.01% ongoing maintenance).

The result: 70% reduction in manual touchpoints. 250+ hours recovered annually for senior management. System still running two years later. Maintenance: 15 minutes monthly.

If we'd gone with the expensive software, we'd be paying SGD 50K yearly, dealing with vendor support tickets, and still have had a workflow designed for other companies, not ours.

What I learned: Software vendors sell software. They benefit when you buy more features. You benefit when you buy fewer features that work well.

Example 4: 2024 - Mobile SAP Integration (Age 32)

The constraint: No app budget. Field teams needed to verify device serial numbers instantly from anywhere.

The problem: Verification data lives in SAP. SAP access requires desktop, training, login credentials. Field engineers working in clinics, hospitals, remote locations couldn't access it. Process: manually contact office, wait for response, verify by phone. Total time: 5-8 minutes per device.

Why expensive wouldn't work: Building a proper mobile app: SGD 50K-100K. Six months development time. IT approval required. Still wouldn't be faster than desktop SAP once built.

What I built instead: Automated weekly extraction from SAP to Excel. Optimized Excel layout for mobile (large buttons, simple interface). Field team opens it on any phone. Lookup takes 30 seconds.

The expensive solution: Build a mobile app (SGD 50K-100K, 6 months, ongoing maintenance). The simple solution: Use technology everyone already has (phone) with data format everyone already knows (Excel). One day to build.

The result: 100% adoption. Verification time: 5-8 minutes → 30 seconds. No training needed (people know Excel). Zero licensing cost. Deployable to every APAC country instantly.

The app would have been fancy. The Excel solution actually works better.

What I learned: The best technology is often the one that's already in everyone's pocket.

The Anti-Pattern: Why Expensive Solutions Usually Fail

I've seen this repeatedly. When organizations have budget, they tend to:

1. Buy complexity Enterprise software comes with features for every possible use case. You implement 20% of the features for 200% of the cost. The system becomes so complex that only specialists can maintain it.

2. Lose ownership External vendors or IT departments become the keepers of the system. When something breaks, you wait for them. When you need a change, you request and wait. Friction compounds.

3. Overcomplicate the problem When you have a big budget, problems expand to fill it. What could be solved with a simple workflow becomes a "digital transformation initiative." A one-week project becomes a six-month program. Process bloat increases.

4. Build for tomorrow's problems Expensive solutions get justified by future scenarios. "We might need to integrate with X system." "We'll eventually expand to Y countries." You're paying for complexity you might never use.

5. Create fragility Complex systems are fragile. One component breaks, the whole system fails. Simple systems are redundant. One part fails, you have workarounds.

The pattern is consistent: More budget → More complexity → More cost → Less maintainability → Worse outcomes.

The organizations I've seen do best operate the opposite direction: Minimum budget → Force focus → Simple solutions → High maintainability → Better outcomes.

How This Shapes Thinking

When I approach a problem now, my first question isn't "What's the best solution?" It's "What's the simplest solution that actually works?"

Not simplistic (oversimplified, doesn't address real needs). Simple (elegant, focused, maintainable).

The difference is purpose. A simplistic solution avoids the hard problems. A simple solution solves them with minimal complexity.

For the RMA automation, I could have oversimplified: "Just manually enter everything more carefully." That's simplistic-it avoids the real problem.

Instead, I automated the parts that should be automated (parsing, classification, routing) and kept human judgment for the parts that need it (unusual cases, edge conditions). That's simple.

The checklist I use:

Can this be solved with what we already have? (If yes, start there)
What's the 80/20 split-what's common vs. rare? (Automate common, flag rare for review)
Who owns this after I leave? (If I can't explain it in 30 minutes, it's too complex)
What breaks when this fails? (Build redundancy for critical parts)
How much time am I spending on maintenance? (If >1% of the value it creates, redesign it)

How To Start Using This Philosophy

You don't need to be in a resource-constrained situation to benefit from this thinking.

Even if you have a big budget, you can choose to operate like you don't.

Start by removing budget assumptions from your problem-solving.

Don't say: "What software should we buy?" Say: "What could we achieve with zero new spending?"

Don't start with: "What's the enterprise solution?" Start with: "What's the simplest thing that might work?"

Don't build for: "What we might need eventually" Build for: "What solves this today"

Then, when you're ready to add resources, you add them strategically to a base that already works-instead of starting with the assumption that you need big spending from day one.

The best systems I've built have always followed this pattern: Solve it simply first. Then optimize if needed. Most of the time, simple is good enough.

And when you can say that, you've built something that lasts.