DEV Community: Ritesh Rajpurohit

Building Secure, Observable Treasury Vaults on Stellar with Soroban

Ritesh Rajpurohit — Fri, 17 Jul 2026 18:21:57 +0000

In the fast-evolving decentralized finance (DeFi) landscape, managing treasury reserves safely and transparently is a core requirement for any Web3 organization. Whether you are running a Decentralized Autonomous Organization (DAO), managing venture funding, or distributing developer bounties, you need two things: rock-solid security on-chain and clear observability off-chain.

In this article, we’ll walk through how we built Stellar Vault Ops—a production-grade Web3 vault operations dashboard built on Stellar Mainnet using Soroban smart contracts, Freighter wallet integration, and a real-time React dashboard. We will explore the contract design patterns, inter-contract calls, and how we solved common transaction UX challenges.

1. The Architectural Blueprint

A secure treasury architecture should avoid monolithic smart contracts. Instead, we follow a modular design, separating asset logic from business workflows:

The Token Contract: A standard asset contract managing balances, minting, and transfers.
The Vault Contract: A specialized treasury manager that holds reserves and coordinates transfers by performing inter-contract calls to the Token Contract.
The Web Console: An operator console that lets admins deposit, distribute, and track transaction states (simulating, signing, submitting, and confirmed) in real-time.

                  +--------------------------------+
                  |       Operator / Admin         |
                  +--------------------------------+
                                  |
                                  v (1. Triggers Action)
                  +--------------------------------+
                  |      React Web Console         |
                  +--------------------------------+
                                  |
                                  v (2. Request Auth & Sign)
                  +--------------------------------+
                  |       Freighter Wallet         |
                  +--------------------------------+
                                  |
                                  v (3. Submit Signed Tx)
                  +--------------------------------+
                  |     Stellar Mainnet RPC        |
                  +--------------------------------+
                                  |
                                  v (4. Invoke)
                  +--------------------------------+
                  |         Vault Contract         |
                  +--------------------------------+
                                  |
                                  v (5. Inter-Contract Call: Transfer)
                  +--------------------------------+
                  |         Token Contract         |
                  +--------------------------------+
                                  |
                                  v (6. Mutate Balances)
                  +--------------------------------+
                  |         Stellar Ledger         |
                  +--------------------------------+

2. On-Chain Logic: Soroban Smart Contracts in Rust

Stellar’s smart contract platform, Soroban, provides a highly performant and secure environment using WebAssembly (WASM). Let’s dive into how our contracts are designed.

A. The Token Contract (`TokenContract`)

The Token Contract tracks state variables in instance storage and exposes standard ERC-20 style endpoints:

#[contractimpl]
impl TokenContract {
    pub fn initialize(e: Env, admin: Address, name: String, symbol: String, decimals: u32) -> Result<(), TokenError> {
        if e.storage().instance().has(&DataKey::Admin) {
            return Err(TokenError::AlreadyInitialized);
        }
        admin.require_auth();
        e.storage().instance().set(&DataKey::Admin, &admin);
        e.storage().instance().set(&DataKey::Name, &name);
        e.storage().instance().set(&DataKey::Symbol, &symbol);
        e.storage().instance().set(&DataKey::Decimals, &decimals);
        e.storage().instance().set(&DataKey::TotalSupply, &0_i128);
        Ok(())
    }

    pub fn transfer(e: Env, from: Address, to: Address, amount: i128) -> Result<(), TokenError> {
        if amount <= 0 { return Err(TokenError::InvalidAmount); }
        from.require_auth();

        let from_balance = read_balance(&e, &from);
        if from_balance < amount { return Err(TokenError::InsufficientBalance); }

        let to_balance = read_balance(&e, &to);
        write_balance(&e, &from, from_balance - amount);
        write_balance(&e, &to, to_balance + amount);
        Ok(())
    }
}

Security Feature: The from.require_auth() assertion guarantees that nobody can move tokens out of a wallet without a cryptographic signature from that wallet.

B. The Vault Contract & Inter-Contract Calls

The Vault Contract is responsible for tracking aggregate deposits and distributions. Rather than holding and ledgering balances itself, it holds the token reserves and calls the Token Contract to perform actual transfers.

Here is how the Vault handles a deposit operation:

pub fn deposit(e: Env, from: Address, amount: i128) -> Result<(), VaultError> {
    if amount <= 0 { return Err(VaultError::InvalidAmount); }
    read_admin(&e)?;
    from.require_auth();

    let token_contract = read_token_contract(&e)?;
    let vault_address = e.current_contract_address();

    // Inter-contract call: transfers tokens from user to this vault
    e.invoke_contract::<()>(
        &token_contract,
        &soroban_sdk::symbol_short!("transfer"),
        soroban_sdk::Vec::from_array(
            &e,
            [
                from.clone().into_val(&e),
                vault_address.into_val(&e),
                amount.into_val(&e),
            ],
        ),
    );

    // Update aggregate metrics
    let next_total_deposited = total_deposited(&e) + amount;
    e.storage().instance().set(&DataKey::TotalDeposited, &next_total_deposited);

    // Publish event
    e.events().publish(
        (soroban_sdk::symbol_short!("deposit"), from.clone()),
        DepositEvent { from, amount },
    );
    Ok(())
}

By leveraging e.invoke_contract(...), the Vault contract keeps a single, secure gateway to execute transfers. The Vault itself does not need to duplicate transfer safety checks, as the Token Contract enforces them during execution.

3. Resolving Web3 UX Challenges: Frontend Observability

Web3 applications frequently suffer from poor feedback loops. Users click a button, sign a transaction, and are left staring at a static loader, wondering if their transaction went through, failed, or timed out.

To solve this in the Stellar Vault Ops console, we built a stateful transaction tracker using React hooks and the Stellar SDK:

Pre-Flight Simulation: Before asking the user to sign, we run server.simulateTransaction(tx). This tests the execution off-chain. If the vault has insufficient funds, we throw a friendly message immediately, preventing wasted gas and user frustration.
Freighter Wallet Integration: We integrate Freighter to securely request signatures. We set a strict SIGN_TIMEOUT_MS (45 seconds) to catch users rejecting or ignoring the popups and return control to the UI.
Optimized Polling & Finality Tracking: Stellar ledgers close every 5-6 seconds. Polling too aggressively can strain RPC nodes, while polling too slowly hurts UX. We built a decaying polling mechanism:
- Poll every 1 second initially.
- If not indexed after 3 attempts, scale to 2 seconds.
- Handle transient RPC union-switch parsing exceptions safely, treating them as pending rather than crashing the interface.

4. Security Audit Insights

Prior to launching on Stellar Mainnet, we conducted a security audit of our Rust code. Here are some of the design trade-offs and findings:

Relayer-Friendly Distributions (Design Choice): In the Vault's distribute method, we check that the contract is initialized, but do not call admin.require_auth(). This allows automated relayer accounts or cron jobs to trigger payouts. If strict control is needed for a corporate treasury, this should be hardened to check permissions.
Instance Storage Expiry: Soroban introduces storage fees and storage expiration. For production scale, switching to persistent data keys for balances and setting up automatic renewal is critical to prevent user funds from freezing if instance rent expires.

5. Mainnet Launch & Adoption

We officially deployed the Stellar Vault Ops smart contracts on the Stellar Mainnet:

Token Contract: CBH5G42NMW7LARIUBBCUUWLA6WJ2Q373QFPQ3YCGRB72JUAVRBIRDEJP
Vault Contract: CC24WFEK4J2XFZL6VSNKTBTCZSQSBOGTCGJ7BFNA4QTG3RY3BHKPMBPL

To validate the deployment, we onboarded 100 active Web3 users who tested deposit, distribution, and monitoring actions on Mainnet. 70% of participants expressed high intent to reuse the dashboard for treasury management, liking the clean dark-mode visuals and the real-time transaction timeline.

Conclusion & Next Steps

Building on Stellar with Soroban offers a robust and highly secure developer experience. The strict separation of concerns, strong typing in Rust, and built-in signature authentication make it an ideal blockchain for treasury and DeFi operations.

In the next iteration of Stellar Vault Ops, we plan to implement:

Multi-signature authentication for distribution operations.
Real-time Slack/Discord webhooks for treasury movement tracking.
Ledger and WalletConnect support.

Check out the full open-source code and onboarding telemetry on our GitHub Repository.

I Read Designing Data-Intensive Applications and Finally Understood System Design

Ritesh Rajpurohit — Wed, 15 Jul 2026 13:52:13 +0000

Recently, I was reading Designing Data-Intensive Applications by Martin Kleppmann, and one quote made me stop for a while:

“There are no solutions; there are only trade-offs. But you try to get the best trade-off you can get, and that’s all you can hope for.”

— Thomas Sowell

This line explains system design better than many tutorials.

When I started learning backend and cloud architecture, I used to search for perfect answers:

Which database is best?
SQL or NoSQL?
Monolith or microservices?
Serverless or containers?
Consistency or availability?
Which AWS service should I use?

But the more I learn, the more I realize that these questions are incomplete.

The better question is:

What trade-off am I choosing, and why?

There is no “best” database

A common beginner question is:

Should I use SQL or NoSQL?

But SQL and NoSQL are not enemies. They are tools with different trade-offs.

A relational database like PostgreSQL or MySQL is great when:

Your data has relationships
You need transactions
You need flexible querying
Correctness is very important

A NoSQL database like DynamoDB is great when:

You need low-latency access at scale
Your access patterns are known
You want predictable performance
You are okay designing around queries first

The trade-off is simple:

SQL gives flexibility. NoSQL gives scale and speed for specific access patterns.

Neither is always better.

It depends on the problem.

Caching makes things faster, but not simpler

Caching sounds like an easy win.

Add Redis. Add CloudFront. Add an in-memory cache. Done, right?

Not really.

Caching improves performance, but it creates new questions:

What if the cache has old data?
When should the cache expire?
What happens if the cache goes down?
Who updates the cache after a database change?

So the trade-off becomes:

Caching gives speed, but adds invalidation and consistency problems.

That does not mean caching is bad. It means caching should solve a real bottleneck, not be added just because it sounds advanced.

Microservices are not automatically better

Microservices look attractive because big companies use them.

But big companies also have big teams, mature DevOps, monitoring, tracing, deployment pipelines, and years of production experience.

For a small team or early product, microservices can create more problems than they solve:

More deployments
More network calls
More failure points
Harder debugging
Distributed data problems
More operational overhead

A monolith may be boring, but boring is often good.

The trade-off is:

A monolith is simpler to build and debug. Microservices help large teams move independently, but add operational complexity.

If your app has 5 users, you probably do not need 12 services.

Consistency vs availability is a real product decision

Imagine you are building an event registration system.

If one part of the system cannot talk to another, what should happen?

Should users still be allowed to register?

Or should the system stop registration until it can guarantee the data is fully correct?

For a casual community event, temporary inconsistency may be acceptable.

For payments, bank transfers, exam results, or ticket inventory, correctness may matter more.

The trade-off is:

Availability keeps the system usable. Strong consistency protects correctness.

The “right” answer depends on what failure your product can tolerate.

AWS services also have trade-offs

Cloud platforms like AWS give us powerful building blocks:

Amazon S3
Amazon EC2
AWS Lambda
Amazon RDS
Amazon DynamoDB
Amazon SQS
Amazon CloudWatch
Amazon CloudFront

But good architecture is not about using the maximum number of services.

Good architecture is using the minimum number of services that solve the problem well.

For example, if I am building a small registration app for a student event, I might start with:

A frontend form
A simple backend
One database
Email confirmation

That may be enough.

If the same system needs to handle thousands of users at once, then I might add:

API Gateway
Lambda
DynamoDB
SQS
CloudWatch
CloudFront

That version is more scalable.

It is also more complex.

So the real question is not:

Can I build it with all these services?

The real question is:

Do I need this complexity right now?

My new system design checklist

After reading this idea, I started asking better questions before choosing tools:

What problem am I solving?
What are the read and write patterns?
What needs to be fast?
What needs to be correct?
What failure can the system tolerate?
What will this cost?
What complexity am I adding?
Can I start simpler?

That last question is important.

Many systems do not fail because they were too simple.

They fail because they became complex before they needed to.

A sentence every engineer should write

Whenever we choose a tool or architecture, we should be able to write this sentence:

We chose ___ because __, but we accept __.

Examples:

We chose PostgreSQL because we need relational data and transactions, but we accept that horizontal scaling may require more planning later.

We chose DynamoDB because we need low-latency reads at scale, but we accept that we must design access patterns upfront.

We chose Lambda because we want event-driven execution without managing servers, but we accept cold starts and service limits.

We chose a monolith because the product is early and the team is small, but we accept that we may split services later if team boundaries demand it.

If you cannot complete this sentence, you may not understand your own architecture yet.

Final thought

The biggest lesson I took from Designing Data-Intensive Applications is this:

System design is not about finding perfect solutions. It is about making informed trade-offs.

There is no perfect database.

No perfect architecture.

No perfect cloud service.

Only context, constraints, and decisions.

Earlier, I used to ask:

What is the right answer?

Now I try to ask:

What trade-off are we choosing, and why?

That one question makes you a better engineer.

Future-Proofing Is a Scam: Buy for Today, Not for an Imagined Tomorrow

Ritesh Rajpurohit — Wed, 29 Apr 2026 18:51:13 +0000

For years, consumers have been sold one powerful idea: spend more today, and you won’t need to upgrade tomorrow.

This logic is everywhere. Buy the highest storage variant. Get the maxed-out processor. Choose the premium model because it will be “future-proof.” Stretch your budget now, and it will supposedly save money later.

It sounds smart. It sounds rational. It sounds like long-term thinking.

But in technology, future-proofing is often a myth.

The Illusion of Paying More to Save Later

Many people justify expensive purchases with a familiar mindset:

“If I buy the best version now, it will last 6–7 years.”
“I’d rather overspend once than upgrade again later.”
“This extra power will become useful in the future.”

The problem is simple: technology does not move linearly. It moves fast, unpredictably, and often aggressively.

What feels “top-tier” today can become average much sooner than expected.

A Real Example

A friend of mine bought a fully upgraded high-end MacBook Pro with an M3 Max chip. He stretched his budget significantly because he believed it would remain unbeatable for many years.

His thought process was understandable:

Massive performance headroom
No need to upgrade for 6–7 years
Best-in-class hardware
Long-term value

But just a short time later, newer generations like M5 Pro chip started closing the gap—or even outperforming it in certain workloads.

Now he realizes something important:

He paid for power he never truly needed, and the “future advantage” disappeared faster than expected.

Performance You Never Use Is Wasted Money

This is where most buyers make mistakes.

They purchase based on potential future needs, not actual current needs.

If your workload today is:

Browsing
Coding
Editing light to moderate videos
Office work
Everyday productivity

Then buying extreme hardware “just in case” often means paying extra for performance that sits unused.

Unused performance has no ROI.

The Better Buying Framework

Instead of asking:

“What will be future-proof?”

Ask:

“What do I need right now, and what will I realistically need over the next 1–3 years?”

That mindset changes everything.

Buy hardware that matches:

Your current workflow
Reasonable short-term growth
Budget discipline
Real usage patterns

Not fantasy scenarios.

Why 1–3 Years Matters More Than 7 Years

Predicting technology over 6–7 years is nearly impossible.

In that time, we see:

Better chips
Faster efficiency gains
New AI features
Improved displays
Better battery life
New software requirements
Price shifts in older devices

Trying to “beat the future” with one oversized purchase usually fails.

But optimizing for the next 1–3 years? That’s realistic, practical, and financially smarter.

What Actually Holds Value

Future-proofing doesn’t protect value. Smart buying does.

The best purchases are often:

Mid-to-upper tier devices
Balanced specs
Models matching your real workload
Products bought at good pricing
Devices upgraded when genuinely needed

Not blindly maxed-out configurations.

Final Thought

Future-proofing sounds wise because it appeals to fear: fear of missing out, fear of becoming outdated, fear of buying “too little.”

But most of the time, it leads to overspending.

Technology evolves too quickly for certainty.

So stop buying for an imaginary future.
Buy for your real present.
Plan for the next few years.
Upgrade when your needs demand it.

That’s not just smarter tech buying.
That’s smarter thinking.

What is a GTM Engineer and Why Your Company Needs One

Ritesh Rajpurohit — Wed, 01 Apr 2026 21:49:13 +0000

In today’s fast-paced, AI-driven sales landscape, the role of a GTM Engineer is becoming indispensable. GTM (Go-To-Market) Engineers are the unsung heroes behind predictable and scalable revenue growth. But what exactly do they do, and why might your company need one?

What is a GTM Engineer?

A GTM Engineer is a specialist who combines automation, AI, and revenue operations to streamline sales processes. They remove the manual bottlenecks in your sales funnel by automating lead qualification, personalized outreach, and data enrichment. Think of them as the architects of automated revenue systems.

Why Did GTM Engineers Emerge?

Traditional outbound tactics have lost effectiveness—cold emails are ignored, and generic outreach is filtered out. Meanwhile, AI and no-code tools have exploded, allowing complex automation without needing a large team of developers. GTM Engineers sit at this intersection—they make relevance scalable and ensure your sales process runs like a well-oiled machine.

What Does a GTM Engineer Actually Do?

Lead Qualification & ICP Mapping: They build systems that identify high-priority accounts based on your ideal customer profile (ICP). AI enriches leads with firmographic data and signals when an account is ripe for outreach.
Data Enrichment: GTM Engineers ensure your lead data is always up-to-date. They integrate multiple data providers, ensuring you never rely on stale or incomplete information.
Outbound Automation: They automate personalized outreach at scale—whether it's email, LinkedIn, or multi-channel plays. Signals like website visits trigger automated, personalized messages that feel handcrafted.
CRM Hygiene: They keep your CRM clean and enriched. Automated workflows update records, extract insights from sales calls, and ensure accurate data for better decision-making.
Customer Success Automation: Even post-sale, they automate churn prediction and upsell opportunities by analyzing usage patterns and customer signals.

Why Your Company Needs a GTM Engineer

If your sales team spends more time on admin than selling, if your lead response time is slow, or if you struggle with data quality, it’s time to hire a GTM Engineer. They won’t just fix processes—they’ll unlock scalable, efficient growth. The future of sales is automated, and GTM Engineers are leading that charge.

Stop Posting Noise: Building in Public Needs Real Value

Ritesh Rajpurohit — Wed, 25 Mar 2026 19:51:56 +0000

“Building in Public” has become one of the most popular trends in the developer ecosystem today. Scroll through LinkedIn, Twitter, or even Instagram, and you’ll see countless posts like:

“Solved 1 LeetCode problem today 🚀”
“Updated my README 💻”
“Day 7 of coding journey ✅”

At first glance, it looks inspiring. People are learning, sharing, and staying consistent. But if we pause for a moment and think deeper — are we actually creating value, or just adding noise?

The Problem with “Low-Value Posting”

Let’s be honest: not everything we do needs to be content.

Solving one basic problem, making a minor README change, or writing a few lines of code — these are important steps in learning, but they are not always meaningful content for others.

When every tiny action is posted:

The signal gets lost in the noise
Platforms get flooded with repetitive updates
Real learning becomes secondary to “just posting something”

It turns into a content race instead of a growth journey.

And the harsh truth?
This doesn’t impress recruiters, developers, or serious builders.

Building in Public ≠ Posting Everything

Building in Public was never meant to be about documenting every micro-step.

It was meant to be about:

Sharing insights
Showing real progress
Teaching what you learned
Being transparent about failures and breakthroughs

There’s a big difference between:

“I solved 1 problem today”

and

“Here’s how I approached a complex problem, what mistakes I made, and what I learned.”

One is an update.
The other is value.

What Actually Matters

If you truly want to build in public the right way, focus on:

Depth over Frequency

Posting daily is good — but only if it adds value.
A single high-quality post per week is better than 7 low-effort updates.

Show Learning, Not Just Activity

Instead of saying what you did, explain:

How you did it
Why you did it
What changed in your thinking

Share Outcomes, Not Just Inputs

People don’t care that you “tried something.”
They care about what you learned, built, or improved.

Respect Attention

Every post consumes someone’s time.
Make sure it’s worth it.

The Bigger Picture

When you fill platforms with low-value content:

LinkedIn becomes cluttered
Twitter becomes repetitive
Even YouTube and Instagram lose depth

You’re not just posting — you’re shaping the ecosystem.

And right now, too much content is being created for the sake of visibility, not value.

Build in Public — But Build with Purpose

Yes, share your journey.
Yes, stay consistent.
Yes, document your growth.

But don’t just post to prove you’re working.

Post to prove you’re learning, improving, and thinking.

Because in the long run:

Builders stand out
Thinkers get noticed
Value creators win

Not people who just post every small step.

Final Thought:
Don’t build content. Build value.
And then share it.

Ready-Made Templates vs Custom Builds — Which Should You Choose for Your Website or App?

Ritesh Rajpurohit — Mon, 09 Mar 2026 20:00:33 +0000

In today’s fast-moving digital world, teams and creators face a common question: should you use a ready-made template for your website or app, or build something custom from scratch? Both approaches have valid reasons and trade-offs. This blog explains those trade-offs in plain English, and shows why starting from a template and smartly customizing it is often the best, most practical path — especially with AI, modern UI/UX, and component-driven coding changing how products are made.

Quick summary (TL;DR)

Templates = speed, lower cost, predictable results. Great for MVPs, landing pages, portfolios, and small businesses.
Custom builds = full control, unique brand experience, and better alignment with complex product needs.
Best middle ground: pick a high-quality template or starter kit, then customize core parts (brand, UX flows, performance) to make it yours. Use AI and component-based design to accelerate the work without sacrificing quality.

Why templates are attractive (Pros)

Fast time to market
Templates give you a working product quickly — sometimes in hours or days. That’s invaluable when you need to test an idea or launch a campaign.
Lower initial cost
Buying or using a free template is cheaper than paying for a full custom design and development cycle.
Proven patterns
Good templates are built with common use cases in mind (navigation, forms, pricing tables), so they reduce design mistakes and UX friction.
Accessible starting point for non-devs
Designers and marketers can get something live without deep coding knowledge; developers can focus on business logic.
Ecosystem & support
Popular templates often come with documentation, updates, and community help — helpful for quick fixes.

Why templates can be limiting (Cons)

Generic look & feel
Many templates look similar to hundreds of other sites. That hurts brand differentiation.
Feature mismatch
Templates may include unneeded features or miss crucial product-specific flows, forcing kludges later.
Performance & bloat
Out-of-the-box templates sometimes include heavy scripts/styles you don’t need, slowing load times.
Technical debt
If the template is poorly written or hard to maintain, customizing it can become more expensive than a clean custom build.
Scalability & uniqueness
For complex apps, templates may not scale well architecturally (APIs, backend logic, advanced interactions).

Why customizing a template is often the smartest move

You get the best of both worlds when you start with a solid template and invest in targeted customization.

Key benefits of customization

Brand authenticity: Tailor typography, spacing, colors, and voice to match your brand vibe.
UX-first flows: Replace generic flows with ones that match your users’ journeys — reduce friction and improve conversions.
Performance optimization: Strip unused code, lazy-load assets, and optimize critical rendering paths.
Accessibility & inclusivity: Ensure the site follows accessibility best practices—important and often missing in templates.
Extendability: Convert a template into a component library or design system so future pages are consistent and fast to build.

The role of AI, “vibe”, and modern UI/UX

AI speeds customization. From generating copy and alt text to suggesting color palettes and auto-generating component code, AI helps you iterate faster without sacrificing thoughtfulness.
“Vibe” matters. Users subconsciously pick up on visual tone — micro-interactions, spacing, and motion. Customizing these elements turns “another template” into a product with personality.
UI/UX is the new differentiator. When core features become commoditized, design and experience differentiate winners. Small, polished interactions and clear signposting often beat flashy but confusing interfaces.
Component and design system approach. Build reusable UI components (buttons, inputs, cards). Once components are polished, scaling UI while maintaining vibe becomes trivial.

Practical decision guide: When to use which approach

Use a template if:

You need to validate an idea fast (MVP).
Budget and time are tight.
The product is content or marketing driven (portfolio, brochure, small store).
You’re comfortable customizing the template or have a dev to do it.

Build custom if:

You need a unique product experience with custom flows.
Security, performance, or compliance is mission-critical.
The product will scale into complex features and integrations.
You want total creative control and long-term maintainability.

Hybrid (recommended) — Template + Customization:

Choose a reputable, minimal template or starter kit (lean, componentized).
Replace brand elements (logo, fonts, color system).
Rework key UX flows (signup, checkout, dashboard).
Remove unused code and optimize performance.
Add analytics, accessibility checks, and CI/CD for maintenance.
Iterate using AI tools for copy, image assets, and prototyping.

Checklist for picking and customizing a template

Is the template lightweight and componentized?
Does its layout match your primary user flows?
Is the code readable and documented?
Can you remove unused features without breaking things?
Is accessibility (keyboard nav, ARIA) considered?
Will the template allow you to implement brand (fonts, color, logo) easily?
Does it support progressive enhancement, responsive behavior, and good performance?
Do you have a plan to track UX metrics post-launch?

Developer’s quick action plan (practical steps)

Audit the template for bloat and third-party scripts.
Create a small design system: colors, spacing, typography, button styles.
Replace placeholders with real content and microcopy.
Test core flows on real users or teammates.
Optimize images, fonts, and defer non-critical JS.
Add analytics and error monitoring.
Iterate based on user feedback and performance data.

Final thoughts

Templates are not “cheap shortcuts” — they’re powerful accelerators when used thoughtfully. The real value comes from intentional customization: preserving the speed and structure of a template while shaping the product with brand, UX, and performance in mind. With AI and modern component-driven workflows, you can move faster than ever without sacrificing quality or uniqueness. In short: start smart, customize strategically, and let UI/UX be your competitive edge.

Why Developers Should Become All-Rounders in the Age of AI 🚀

Ritesh Rajpurohit — Thu, 19 Feb 2026 18:01:07 +0000

For years, the advice was simple:

“Master one skill. Specialize. Go deep.”

And honestly, that made sense.

But today, we’re living in a different world — the Age of AI.

AI can now:

Generate code
Write content
Design interfaces
Analyze data
Debug faster than before

So the question is no longer:

“How deep is your single skill?”

The real question is:

“How adaptable are you?”

A Simple Scenario

Let’s compare two developers:

Developer A

Strong in coding only

Developer B

Basic coding
UI/UX understanding
Knows Git & deployment
Uses AI tools effectively
Good communication
Problem-solving mindset

Now imagine a startup hiring.

They need someone who can:

Build features
Understand users
Ship fast
Fix issues
Learn new tools quickly

Who stands out?

Developer B.

Because today, companies don’t just hire for skills.
They hire for adaptability and ownership.

What Being an All-Rounder Really Means

Being an all-rounder doesn’t mean being average at everything.

It means:

Understanding how the full system works
Learning new tools quickly
Using AI to boost productivity
Connecting design, code, and business
Being able to ship end-to-end

Think of it as becoming a T-shaped developer:

One core strength (e.g., Full Stack)
Basic knowledge across related areas

The Reality of AI

AI will not replace developers.

But:

Developers who use AI effectively will replace those who don’t.

The winning skill today is:

Learning fast
Adapting faster
Using AI as a teammate

How to Become an All-Rounder (Practical Steps)

If you’re a developer, start here:

Learn one core skill deeply (e.g., Full Stack, Backend, etc.)
Understand basics of:
- UI/UX
- System design
- Git & deployment
- APIs
Use AI tools daily (ChatGPT, Copilot, etc.)
Build small end-to-end projects
Share your learnings (blogs, GitHub, DEV)

Final Thought

Instead of asking:

❌ “Should I focus on only one thing?”

Start asking:

✅ “How can I learn faster and adapt continuously?”

Because in today’s tech world,

The future belongs to adaptable developers — not just specialists.

DEV Community: Ritesh Rajpurohit

Building Secure, Observable Treasury Vaults on Stellar with Soroban

1. The Architectural Blueprint

2. On-Chain Logic: Soroban Smart Contracts in Rust

A. The Token Contract (TokenContract)

B. The Vault Contract & Inter-Contract Calls

3. Resolving Web3 UX Challenges: Frontend Observability

4. Security Audit Insights

5. Mainnet Launch & Adoption

Conclusion & Next Steps

I Read Designing Data-Intensive Applications and Finally Understood System Design

There is no “best” database

Caching makes things faster, but not simpler

Microservices are not automatically better

Consistency vs availability is a real product decision

AWS services also have trade-offs

My new system design checklist

A sentence every engineer should write

Final thought

Future-Proofing Is a Scam: Buy for Today, Not for an Imagined Tomorrow

The Illusion of Paying More to Save Later

A Real Example

Performance You Never Use Is Wasted Money

The Better Buying Framework

Why 1–3 Years Matters More Than 7 Years

What Actually Holds Value

Final Thought

What is a GTM Engineer and Why Your Company Needs One

Stop Posting Noise: Building in Public Needs Real Value

Ready-Made Templates vs Custom Builds — Which Should You Choose for Your Website or App?

Quick summary (TL;DR)

Why templates are attractive (Pros)

Why templates can be limiting (Cons)

Why customizing a template is often the smartest move

Key benefits of customization

The role of AI, “vibe”, and modern UI/UX

Practical decision guide: When to use which approach

Use a template if:

Build custom if:

Hybrid (recommended) — Template + Customization:

Checklist for picking and customizing a template

Developer’s quick action plan (practical steps)

Final thoughts

Why Developers Should Become All-Rounders in the Age of AI 🚀

A Simple Scenario

What Being an All-Rounder Really Means

The Reality of AI

How to Become an All-Rounder (Practical Steps)

Final Thought

A. The Token Contract (`TokenContract`)