DEV Community: Jasmine Dueñas

AI Tools That Actually Improved Our Development Workflow in 2026

Jasmine Dueñas — Fri, 03 Jul 2026 06:10:20 +0000

Every few weeks, a new AI coding tool promises to change software development forever.

Some genuinely improve the way teams build software.

Others look impressive in a demo but never become part of a real development workflow.

Over the past year, our engineering team has integrated AI into dozens of client projects across React, Angular, Laravel, Java, Flutter, and WordPress. Along the way, we've learned that the biggest productivity gains didn't come from generating more code. They came from making better engineering decisions earlier.

Some tools became part of our daily workflow.

Others disappeared after a week.

This isn't another roundup of every AI tool released this year.

It's a practical look at the tools we actually use, where they help, where they still struggle, and what we've learned from using them on production projects.

AI Didn't Replace Our Workflow. It Changed It.

When AI coding assistants first became popular, I assumed they would mostly reduce the amount of code developers had to write.

That isn't what happened.

Instead, they changed where we spend our time.

We write less repetitive boilerplate.

We spend more time reviewing implementations, validating business logic, discussing architecture, improving performance, and thinking about long-term maintainability.

Ironically, AI has made engineering judgment even more valuable.

The better the developer, the more useful these tools become.

ChatGPT Became Our Engineering Thought Partner

People often assume ChatGPT is mainly for generating code.

For our team, that's actually one of its smaller jobs.

Most of the time, we use it before we start coding.

It helps us compare implementation approaches, explain unfamiliar errors, brainstorm architecture ideas, draft documentation, and challenge our own assumptions.

Instead of asking:

Build this feature.

We're more likely to ask:

What problems could this implementation create six months from now?

Which approach would another developer find easier to maintain?

That small change completely changed how useful ChatGPT became.

Instead of replacing engineering decisions, it helps us make better ones.

Claude Handles Large Codebases Exceptionally Well

Claude has become our first choice whenever we're working inside larger repositories.

One thing it consistently does well is follow context across multiple files.

We've used it to trace bugs through legacy Laravel applications, review Angular feature updates before deployment, understand older Java services, improve Flutter features, and simplify complex business logic that had grown difficult to maintain.

We've also found that prompt quality matters far less than context.

This rarely produces useful results:

Fix my checkout bug.

This usually does:

The checkout form in src/components/Checkout.jsx submits twice on slow connections.

Find the race condition, explain why it happens, and suggest the safest fix without changing existing business logic.

The more context we provide, the better the answers become.

Cursor Feels More Like Pair Programming

Cursor changed the way we build new features.

Instead of constantly switching between an IDE and a browser, AI stays inside the editor while we're already working.

A typical workflow looks like this:

Create the files.
Describe the feature.
Let Cursor scaffold the first implementation.
Review every change.
Continue building from there.

We rarely accept everything AI writes.

Instead, we treat it like a junior developer who works incredibly fast but still needs experienced review.

That mindset has worked much better than expecting perfect code.

JetBrains AI Fits Naturally Into Daily Development

For developers using PhpStorm or IntelliJ IDEA, JetBrains AI feels like a natural extension of the IDE.

We mostly use it for repetitive tasks, quick refactoring, explaining unfamiliar code, generating documentation, and speeding up routine Java and Laravel development.

Sometimes convenience is just as important as model quality.

If the tool fits naturally into your workflow, you're much more likely to use it consistently.

TL;DV Saves More Time Than Any Coding Tool

One of the most valuable AI tools we use doesn't generate code at all.

TL;DV records meetings, creates searchable transcripts, summarizes discussions, and extracts action items automatically.

Instead of assigning someone to write meeting notes, everyone can focus on the conversation while documentation happens in the background.

For engineering teams that regularly work with clients, that has saved us a surprising amount of time.

Not Every AI Tool Earned a Permanent Spot

One thing we've learned is that impressive demos don't always translate into daily productivity.

Some tools generated decent code but struggled with larger repositories.

Others required so much prompt engineering that writing the solution ourselves was actually faster.

The tools that lasted weren't necessarily the smartest.

They were the ones that fit naturally into our existing workflow.

That's become one of the biggest lessons we've learned about adopting AI.

AI Still Makes Expensive Mistakes

Despite how capable these tools have become, they're still capable of introducing technical debt.

Some of the issues we've repeatedly encountered include:

Duplicated business logic
Unnecessary abstractions
Inefficient database queries
Inconsistent validation
Ignoring existing coding standards
Missing authorization checks
Solutions that technically work but become difficult to maintain

One example involved AI generating validation logic across several controllers.

Nothing broke.

The application behaved correctly.

Tests passed.

But every future business rule would have required updating multiple files.

That's technical debt introduced on day one.

AI optimized for getting the feature working.

It didn't optimize for long-term maintainability.

That's still our responsibility.

None of the AI-generated code goes directly into production. Every suggestion is reviewed, tested, and adapted by an engineer before it becomes part of a client project.

Flutter Still Requires More Guidance

One pattern we've consistently noticed is that AI performs better with JavaScript and PHP ecosystems than Flutter.

That's less about Flutter itself and more about the amount of publicly available training data.

When working with Flutter, especially Bloc state management or larger widget trees, we usually provide much more context than we would for React or Laravel projects.

The difference in output quality is noticeable.

Five Lessons We've Learned

After using AI every day on production software, a few lessons stand out.

1. Context matters more than prompt engineering.

Good context consistently produces better answers than clever prompts.

2. Reviewing AI-generated code is more important than generating it.

The first draft is rarely the final implementation.

3. AI removes repetitive work, not engineering responsibility.

Developers still own quality, testing, security, and maintainability.

4. Architecture is still a human decision.

AI can recommend patterns, but it doesn't understand business priorities, budgets, or future product direction.

5. The best AI tool is the one your team naturally enjoys using.

Consistency creates more value than constantly switching to the newest release.

Our Technology Stack Didn't Change. We Just Became Faster.

AI hasn't replaced the technologies we build with.

We still choose the right framework for the project.

Sometimes that's React.

Sometimes Angular.

Sometimes Laravel.

Sometimes Java.

Sometimes Flutter.

Sometimes WordPress.

The biggest difference is that repetitive work now takes minutes instead of hours.

That gives us more time to focus on solving business problems instead of writing boilerplate.

For organizations building software that needs to scale, AI is a powerful accelerator, but long-term success still depends on thoughtful architecture, code quality, and experienced engineering. That's why many businesses continue to invest in custom software development services.

The Biggest Lesson

A year ago, I thought AI would mostly change how developers write code.

Today, I think it's changing how developers think.

I write less boilerplate.

I spend more time reviewing.

I ask better questions before implementing a solution.

I think more carefully about maintainability.

If someone asked me to give up one AI tool tomorrow, I'd still be able to build software.

If they asked me to give up engineering judgment, none of these tools would matter.

That's probably the biggest lesson AI has taught me over the past year.

The teams getting the most value from AI aren't replacing developers.

They're combining AI's speed with human experience, thoughtful code reviews, and good engineering decisions.

That's where we've seen the biggest improvements.

What AI tools have actually stayed in your workflow?

I'm especially interested in hearing from developers working with Laravel, React, Angular, Java, Flutter, or WordPress.

Which tools genuinely improved your day-to-day work, and which ones didn't live up to the hype?

Web Development Best Practices That Actually Matter in Production

Jasmine Dueñas — Fri, 26 Jun 2026 04:34:45 +0000

There's no shortage of "best practices" lists online, but most of them read like documentation summaries copied from the same three sources. This one comes from real projects: client sites that went live, broke, got fixed, and eventually scaled.

I'm a full-stack engineer based in Cebu. I've worked on everything from Laravel + React business platforms to mobile-adjacent web apps. The practices below are the ones we actually enforce on every project, not just the ones that sound good in a sprint planning meeting.

Structure Your Project Before You Write a Single Line

The biggest source of technical debt I've seen isn't bad code. It's unplanned code. Developers who jump straight into features without agreeing on folder structure, naming conventions, or data flow end up with inconsistency that compounds every sprint.

Before kickoff, lock in: folder structure (by feature, not by type), naming conventions, state management approach, and API contract. For React, a feature-based structure ages better:

src/
  features/
    auth/
      components/
      hooks/
      authSlice.ts
  shared/
    components/
    utils/

Co-located code onboards faster and breaks less when the team grows.

Keep Your Code Readable and Maintainable

Write for the next developer, and not just the compiler. Code that works is the floor. I've inherited codebases where everything ran fine but no one could safely touch anything: variable names like x and tempFinal, functions 100 lines long doing five different things, zero comments explaining why anything was built the way it was.

Three habits that compound over time: apply DRY (duplicated logic means duplicated bugs), comment the why not the what, and keep functions short and focused.

// Bad: one function doing everything
function processFormData(data) {
  // validate, transform, submit, handle errors — all 80 lines of it
}

// Better: single responsibility per function
function validateInput(data) { ... }
function transformPayload(data) { ... }
function submitForm(payload) { ... }

In React projects specifically, this maps directly to component design. A component that fetches data, transforms it, and renders UI is three jobs in one. Split them. Your future self will thank you when a requirement changes.

Hit Your Core Web Vitals Targets

Google uses Core Web Vitals as ranking signals. More importantly, they correlate directly with whether users stay or leave. The targets:

LCP (Largest Contentful Paint): under 2.5 seconds. Usually your hero image or main above-the-fold block.
INP (Interaction to Next Paint): under 200ms. Replaced FID. Measures how responsive the page feels to input.
CLS (Cumulative Layout Shift): under 0.1. Set explicit dimensions on images and embeds so the layout doesn't jump as assets load.

What actually moves these numbers:

Lazy load non-critical assets. Native loading="lazy" on below-the-fold images. Code-split routes in your JS bundle.

const Dashboard = React.lazy(() => import('./features/dashboard/Dashboard'));

<img src="screenshot.webp" loading="lazy" width="800" height="450" alt="Dashboard view" />

Serve images in WebP or AVIF. A well-compressed WebP is typically 25-35% smaller than an equivalent JPEG with no visible quality loss.

Compress text assets. Enable Brotli on your server. It compresses JS and CSS 15-20% better than Gzip. If your host doesn't support Brotli, Gzip is non-negotiable.

Use a CDN. For Philippine-based projects, CDNs with Asia-Pacific edge nodes make a measurable difference. Cloudflare's free tier covers the basics.

Fix N+1 queries. A slow API tanks INP just as much as a heavy JS bundle. In Laravel:

// N+1: one query per user
$users = User::all(); // then loops hitting orders

// Fixed: two queries total
$users = User::with('orders')->get();

Security Is Not Optional on Client Work

When you're building for a business, their user data is your responsibility during the build. Non-negotiables:

Sanitize all inputs. Every field, every endpoint. XSS and SQL injection are still the most common vulnerabilities in production apps and both are entirely preventable.

Use parameterized queries. Never concatenate user input into a SQL string.

Configure a Content Security Policy. A CSP header restricts which scripts and resources can execute on your page. One of the most effective XSS mitigations available:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';

Keep dependencies updated. Outdated packages are the most overlooked attack surface. Run npm audit or composer audit regularly. Critical vulnerabilities are bugs, not backlog items.

Set CORS correctly. Wildcard * origins on a production API is a hole, not a convenience.

Store secrets in environment variables. If a credential is in your repo, assume it's compromised.

HTTPS everywhere. Let's Encrypt is free. There is no valid reason for HTTP on a production site.

I run a quick OWASP Top 10 check before every client handoff. Two hours. Has caught real issues more than once.

Accessibility Is a Technical Requirement, Not a Nice-to-Have

This is the section most "best practices" articles skip. Accessibility affects real users and in many markets it's a legal requirement. From a pure SEO angle: screen readers and Google's crawler parse your markup the same way. Semantic, accessible HTML directly improves indexability.

Use semantic HTML. <main>, <nav>, <article>, <header>, <footer> carry meaning. A <div> soup does not.

<!-- Avoid -->
<div class="nav">...</div>
<div class="content">...</div>

<!-- Prefer -->
<nav aria-label="Main navigation">...</nav>
<main>...</main>

Support keyboard navigation. Every interactive element should be reachable via Tab and operable via Enter. Add visible :focus styles. Removing them because they look ugly locks out keyboard-only users entirely.

Check color contrast. WCAG 2.1 AA requires 4.5:1 for normal text. Low contrast is the most common accessibility failure on business sites.

Write meaningful alt text. Not alt="image". Describe what the image shows. For purely decorative images, use alt="" so screen readers skip them.

Spend 30 minutes with NVDA (free, Windows) or VoiceOver (built-in on macOS). Manual testing catches what automated tools miss.

Build for Mobile First, Not Mobile After

Over 70% of web traffic in the Philippines comes from mobile devices. If you're designing and coding desktop-first, you're retrofitting at the end of every sprint, and it shows.

Mobile-first CSS starts at the smallest breakpoint and adds complexity upward:

/* Base: mobile */
.card {
  padding: 1rem;
  flex-direction: column;
}

/* Tablet and up */
@media (min-width: 768px) {
  .card {
    padding: 2rem;
    flex-direction: row;
  }
}

It's a discipline shift, not a major refactor. Teams that build mobile-first consistently ship fewer regressions on small screens.

Automate What Doesn't Need Human Eyes

Manual deployments are a liability. Steps get skipped, run out of order, or executed on the wrong branch.

Minimum viable CI/CD: lint on every push, run automated tests on PRs, use environment-specific configs for dev/staging/production, and include npm audit in the pipeline so dependency vulnerabilities don't slip through. GitHub Actions is free for public repos. There's no good reason to skip this.

Document Before You Hand Off

This gets skipped on almost every project. By delivery, everyone's tired and a README feels like overtime.

But a client who can't operate the system without the original developer is a support burden that follows you. Cover the basics: local setup, deployment steps, where secrets live, and what third-party services are integrated and why.

If you're working with a custom software development company in the Philippines, documentation quality is one of the fastest signals that they've shipped real projects before. A README that actually works is a professional differentiator. Most don't have one.

Consistency Beats Cleverness

The best codebase I've worked on wasn't the most technically impressive one. It was the most consistent one: same patterns everywhere, same naming, same error handling. Any developer could be productive in under an hour.

Clever code is satisfying to write and painful to maintain. Boring, consistent code ships faster, breaks less, and onboards better.

If you're evaluating a web development company in the Philippines for a long-term project, ask how they handle code reviews and whether they enforce conventions team-wide. That answer tells you more about maintainability than any tech stack claim.

FAQ

What's the most common code quality mistake on team projects?
No agreed conventions before writing starts. Folder structure, naming, state management approach, error handling patterns. If these aren't locked in at kickoff, every developer solves them differently. By sprint three you have five styles in one codebase and nobody wants to touch anything they didn't write.

What's the single fastest performance win?
Convert images to WebP or AVIF and set explicit dimensions. Usually the biggest LCP improvement and takes under an hour.

How do I start with accessibility if I've never done it before?
Run your page through the WAVE browser extension and fix everything it flags. Then navigate your own site using only a keyboard. That combination surfaces most critical issues.

What's a safe starting CSP?
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; Start strict and loosen only where your app explicitly needs external resources.

How often should dependencies be updated?
Monthly for minor updates. Security patches flagged as critical: same week. Stale dependencies are an underestimated attack surface.

These practices aren't individually groundbreaking. The value is in applying them as a system, consistently, from the start. The codebases that age well and the ones that become nightmares differ almost entirely on whether these fundamentals were treated as optional.

What does your team enforce that didn't make this list? Drop it in the comments.

Why We Use Flutter for Mobile App Development

Jasmine Dueñas — Wed, 17 Jun 2026 06:08:38 +0000

When you're building a mobile app that needs to launch on both iOS and Android, the framework you choose has a direct impact on development speed, maintenance costs, and long-term scalability.

Over the years, we've shipped projects using both native and cross-platform technologies. While every framework has tradeoffs, Flutter has become our default choice for most client projects because it strikes a balance between developer productivity, performance, and platform consistency.

Here's what we've learned.

One Codebase, Actually One Codebase

The "write once, run anywhere" promise has been repeated so many times that most developers are naturally skeptical.

Flutter comes closer to delivering on that promise than most alternatives because it uses its own rendering engine rather than relying on native UI components. Instead of maintaining separate component trees or dealing with platform-specific inconsistencies, the same widget hierarchy powers both Android and iOS.

For teams working with limited budgets or tight launch schedules, this means less duplicated effort and fewer platform-specific bugs. Features can be developed, tested, and released across both platforms simultaneously without maintaining two separate codebases.

Dart Is Easy to Pick Up (and Surprisingly Fast)

One of the biggest concerns developers have when approaching Flutter is Dart.

Dart gets more criticism than it probably deserves. If you've used JavaScript, TypeScript, Java, or C#, you'll feel comfortable pretty quickly. Its syntax feels familiar, while its strong typing and tooling help catch issues before they reach production.

class CounterPage extends StatefulWidget {
  const CounterPage({super.key});

  @override
  State<CounterPage> createState() => _CounterPageState();
}

class _CounterPageState extends State<CounterPage> {
  int _count = 0;

  void _increment() {
    setState(() {
      _count++;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Text(
          '$_count',
          style: const TextStyle(fontSize: 48),
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _increment,
        child: const Icon(Icons.add),
      ),
    );
  }
}

Because Flutter uses ahead-of-time (AOT) compilation, applications feel responsive and performant even on mid-range devices. Combined with Flutter's hot reload capabilities, development remains fast without sacrificing runtime performance.

Hot reload deserves special mention. Seeing UI updates reflected almost instantly while preserving application state significantly shortens the feedback loop during development.

Widget Tree Architecture Keeps Things Predictable

Everything in Flutter is a widget.

Layouts, styling, animations, spacing, and user interactions all follow the same composable model. While it can feel verbose initially, the consistency pays off as projects grow.

Once developers understand a handful of core layout widgets like Row, Column, Stack, and Expanded, building complex interfaces becomes much more predictable. Rather than learning multiple layout systems, teams work within a single mental model across the entire application.

Widget build(BuildContext context) {
  return Padding(
    padding: const EdgeInsets.all(16),
    child: Column(
      crossAxisAlignment: CrossAxisAlignment.start,
      children: [
        Text(
          'Project Title',
          style: Theme.of(context).textTheme.headlineSmall,
        ),
        const SizedBox(height: 8),
        Row(
          children: [
            const Icon(Icons.calendar_today, size: 16),
            const SizedBox(width: 4),
            Text('Due: June 30'),
          ],
        ),
      ],
    ),
  );
}

This consistency also makes onboarding easier. New developers can quickly understand how screens are structured without learning project-specific conventions.

State Management Has Matured

State management used to be one of Flutter's most debated topics.

Today, the ecosystem has matured considerably. Popular solutions like Riverpod and Bloc are well documented, actively maintained, and battle-tested in production environments.

For most of our projects, Bloc is the preferred choice. It enforces a strict separation between UI and business logic through an explicit event-state model, which keeps large codebases organized and makes debugging significantly easier. When something goes wrong, you can trace exactly which event triggered which state change.

// Events
abstract class UserEvent {}
class FetchUser extends UserEvent {}

// States
abstract class UserState {}
class UserLoading extends UserState {}
class UserLoaded extends UserState {
  final User user;
  UserLoaded(this.user);
}
class UserError extends UserState {
  final String message;
  UserError(this.message);
}

// Bloc
class UserBloc extends Bloc<UserEvent, UserState> {
  final UserRepository repository;

  UserBloc(this.repository) : super(UserLoading()) {
    on<FetchUser>((event, emit) async {
      emit(UserLoading());
      try {
        final user = await repository.fetchCurrentUser();
        emit(UserLoaded(user));
      } catch (e) {
        emit(UserError(e.toString()));
      }
    });
  }
}

// In the widget
BlocBuilder<UserBloc, UserState>(
  builder: (context, state) {
    if (state is UserLoading) return const CircularProgressIndicator();
    if (state is UserError) return Text('Error: ${state.message}');
    if (state is UserLoaded) return Text('Welcome, ${state.user.name}');
    return const SizedBox();
  },
);

While teams may still prefer different approaches, Flutter's state management story is far stronger than it was a few years ago.

It Scales Beyond Mobile

One thing that surprised us when we started using Flutter seriously was how easy it was to extend projects beyond mobile.

Beyond Android and iOS, Flutter can also compile for desktop and web. While platform-specific adjustments are sometimes necessary, the ability to reuse business logic, design systems, and application architecture across platforms can significantly reduce development overhead.

We've seen this become particularly valuable when project requirements evolve. A mobile-first application can later expand into desktop or web experiences without requiring a complete rebuild from scratch.

The Philippine Context

For teams building software for Philippine businesses, Flutter often hits a practical sweet spot.

Many organizations want to launch on both Android and iOS but don't necessarily have the resources to maintain separate native development teams. Flutter makes it possible to deliver polished applications across both platforms while keeping development and maintenance costs manageable.

The local Flutter ecosystem has also matured significantly. Active communities, meetups, and experienced developers throughout the country make hiring and collaboration far more accessible than it was during Flutter's early years.

What Flutter Doesn't Do Well

No framework is perfect, and Flutter is no exception.

Complex platform integrations may still require native Android or iOS development.
Application sizes tend to be larger than equivalent native applications.
Flutter Web continues to improve but is generally better suited for application-style experiences than content-heavy marketing websites.
Teams heavily invested in JavaScript may find React Native easier to adopt initially.

Understanding these limitations is just as important as understanding the benefits.

FAQ

Is Flutter better than React Native?

It depends on your team's priorities.

If your developers are already deeply invested in the JavaScript ecosystem, React Native offers a lower learning curve. If rendering consistency, platform parity, and predictable UI behavior are priorities, Flutter is often the stronger choice.

Do I need to know Dart before learning Flutter?

No. Most developers learn Dart while learning Flutter. The language is approachable and shares many concepts with other modern programming languages.

Can Flutter apps be submitted to both the App Store and Google Play?

Yes. A single Flutter project can generate platform-specific builds for both iOS and Android and follow the same publishing process as native applications.

How does Flutter handle offline support?

Flutter itself focuses on the UI layer. Offline functionality is typically implemented using local databases and synchronization strategies, making robust offline experiences entirely achievable with the right architecture.

Is Flutter production-ready?

Absolutely.

Flutter powers production applications used by startups, enterprises, and large technology companies worldwide. The framework has matured significantly, with a stable ecosystem, strong tooling, and a large developer community supporting long-term adoption.

Final Thoughts

Flutter isn't perfect, and it's definitely not the right tool for every project.

There are still cases where native development makes more sense. React Native can also be a great option, especially for teams that already live in the JavaScript ecosystem.

That said, Flutter has become our default choice for most mobile projects. It helps us move faster, maintain a single codebase, and deliver a consistent experience across Android and iOS without doubling development effort.

If you're currently planning a new application, it helps to work with a team that has already shipped Flutter apps in production. A mobile app development company in the Philippines with real-world Flutter experience can help you avoid technical and architectural problems that usually don't show up until much later in the project.

What are you using for mobile development these days? Flutter, React Native, native, or something else? I'd love to hear what's working for your team.

React vs. Angular: Which One Should You Use for Your Next Web Project?

Jasmine Dueñas — Mon, 08 Jun 2026 05:35:23 +0000

If you're choosing between React and Angular right now, the honest answer is: it depends on what you're actually building, not on which one has more GitHub stars.

I've worked on projects that used both, and I've seen teams pick the wrong tool because they followed hype instead of requirements. This isn't a "React always wins" or "Angular is enterprise-grade therefore serious" post. It's a breakdown of when each one actually makes sense.

The Core Difference You Need to Understand First

React is a library. Angular is a framework.

That distinction matters more than most comparisons let on.

React gives you a view layer and lets you assemble everything else: routing, state management, form handling, HTTP calls. You pull in what you need. This flexibility is a feature and a trap, depending on your team.

Angular gives you the whole kitchen. Routing, forms, HTTP client, dependency injection, a CLI, testing utilities, and a strongly opinionated project structure are all included. You don't have to make decisions about tooling because Angular already made them for you.

# Starting a React project (Create React App or Vite)
npx create-react-app my-app
# or
npm create vite@latest my-app -- --template react

# Starting an Angular project
npm install -g @angular/cli
ng new my-app

The Angular setup asks you upfront: do you want routing? Which stylesheet format? React just... starts. You figure it out as you go.

When React Makes More Sense

React is the better pick when:

You need flexibility over convention. If your app has unusual data flow, a non-standard architecture, or you're integrating with an existing system, React's composability is a real advantage. You're not fighting the framework.

Your team is already JavaScript-heavy. React is closer to vanilla JS than Angular. There's no need to learn TypeScript from day one (though you should), no decorators, no module system to learn separately. The ramp-up for a mid-level JS dev is faster.

You're building a content-heavy or marketing-focused product. React's ecosystem around SSR and static generation (Next.js specifically) is more mature and has broader community support for SEO-sensitive use cases. If your project needs good page speed scores and crawlable content, Next.js gives you that out of the box.

You want a smaller initial bundle. React itself is around 40KB minified. What you add on top is your call.

Here's a simple React component to show how straightforward the mental model is:

function ProductCard({ name, price, inStock }) {
  return (
    <div className="card">
      <h2>{name}</h2>
      <p>₱{price.toLocaleString()}</p>
      {inStock ? <span className="badge">Available</span> : <span className="badge out">Out of Stock</span>}
    </div>
  );
}

No decorators, no modules, no injected services. Just a function that returns UI.

When Angular Makes More Sense

Angular earns its place when:

You're building a large, team-maintained application. Angular's strong conventions mean less code review debate about structure. Everyone knows where services go, where components go, what the module boundary is. On a 10-person team working on a single codebase for two years, that consistency saves real time.

TypeScript is non-negotiable. Angular is TypeScript-first. The type safety is baked in everywhere: services, components, HTTP calls, forms. If your team is already comfortable with TypeScript and values catching errors at compile time, Angular's strictness is a feature.

You're building form-heavy enterprise apps. Angular's Reactive Forms are genuinely good. Complex validation logic, dynamic form fields, nested form groups: all of it is handled cleanly without reaching for external libraries.

// Angular Reactive Form example
this.contactForm = this.fb.group({
  name: ['', [Validators.required, Validators.minLength(2)]],
  email: ['', [Validators.required, Validators.email]],
  message: ['', Validators.required]
});

Your team prefers opinionated structure. Some teams work better when there's a "right way" enforced by the framework. Angular provides that. React's flexibility can lead to inconsistency across a codebase without strong internal conventions.

The Performance Conversation (It's More Nuanced Than You Think)

Both are fast enough for most web apps. The performance gaps you read about in benchmarks rarely surface in production unless you're doing something extreme.

What actually affects performance in both frameworks:

How you handle state updates and avoid unnecessary re-renders
Whether you're lazy-loading routes and components
How you manage large lists (virtualization matters more than your framework choice)
Your bundle splitting strategy

React's virtual DOM and Angular's change detection both work well when used correctly. The bottleneck in most real-world apps is network latency, API response times, and image optimization, not the framework's rendering approach.

If raw performance for data-heavy dashboards is a priority, it's worth looking at how providers of custom web development services select frameworks based on actual project requirements rather than default preferences.

What About the Job Market and Ecosystem?

React has more jobs, more packages, more Stack Overflow answers, and more tutorials. That's just true. The ecosystem is larger.

Angular has more stable, long-term support from Google and a more predictable upgrade path for large codebases. Angular's breaking changes are communicated well and migration guides are detailed.

If you're an early-career dev trying to maximize employability, React is the safer bet right now. If you're joining or building a team working on complex enterprise software, Angular experience is valuable and often specifically required.

My Actual Recommendation

Stop asking "which is better" and start asking "which fits this project."

For a startup's MVP or a marketing site with dynamic elements: React (probably with Next.js).

For an internal enterprise app with complex forms, multiple user roles, and a large dev team: Angular.

For a small personal project or learning exercise: React, because the faster feedback loop is better for learning.

For a team that has already standardized on one: use what the team knows. Switching frameworks mid-project is almost never worth it.

One thing I've noticed working on Philippine tech projects specifically: the local talent pool leans React-heavy. If you're hiring locally and building a team from scratch, React gives you a wider candidate pool. That's a practical consideration that framework comparison articles rarely mention.

If you're unsure what makes sense for your specific project context, teams that specialize in web application development can usually give you a clearer answer after understanding your actual requirements, not just your tech preferences.

Quick Comparison Table

Factor	React	Angular
Type	Library	Full framework
Language	JS or TS	TypeScript (required)
Learning curve	Lower	Steeper
Flexibility	High	Lower (opinionated)
Bundle size (base)	~40KB	~130KB
SSR support	Via Next.js	Angular Universal
Best for	Flexible UIs, content sites	Enterprise apps, large teams
Job market	Larger	Smaller but consistent

FAQ

Can I use TypeScript with React?
Yes, and you should for any serious project. Create React App and Vite both have TypeScript templates. The ecosystem support is solid.

Is Angular dying?
No. Angular releases regular updates, Google actively uses it internally, and it's widely used in enterprise environments. The community is smaller than React's but it's stable and maintained.

Which is easier to learn first?
React. The concepts are closer to base JavaScript and the tooling is less opinionated, which means less to learn upfront.

Can I switch from React to Angular later?
Technically yes, but it's a significant rewrite. Make the decision early and commit to it.

Which one does Google prefer?
Google built Angular. But Google also uses React internally for some products. Neither has a SEO advantage just from the framework choice: what matters is how you implement rendering.

What's your current stack? Are you on React, Angular, or something else entirely (Vue, Svelte, plain JS)? Drop it in the comments. Curious what the Dev.to crowd is actually shipping with these days.

How to Build a SEO-Ready Website Before You Launch (And Why Most Teams Get This Wrong)

Jasmine Dueñas — Thu, 04 Jun 2026 07:02:34 +0000

Launching a website without SEO foundations baked in is like building a shop in an alley with no signage. Great product, zero foot traffic.

Most teams treat SEO as a post-launch task. "We'll optimize it later." But some of the most expensive SEO problems, like broken crawlability, wrong URL structure, and missing analytics, are decisions that hardened during development. By the time someone notices, fixing them means touching templates, redirects, and sometimes the CMS itself.

This guide covers what actually needs to happen before go-live. Not theory. This is the checklist we use at our Cebu-based web development company.

What "SEO-ready" really means

It does not mean stuffing keywords into page titles. A site is SEO-ready when it can be:

Discovered: search engines can find and index the right pages
Understood: each page has clear structure, a defined topic, and proper metadata
Used: fast on mobile, accessible, with obvious next steps
Measured: analytics and Search Console are live and tested before launch day

If any of those four are missing, you are not ready.

Phase 1: Plan before a single template gets built

The best time to fix SEO is before URLs are locked and templates are baked into the CMS. Once development hardens, changes cost real time and money.

Start from business goals, not a keyword list

Keywords are reference material, not copy-paste phrases. Start here instead:

What should this site generate? Inquiries, demo requests, bookings?
Who is the buyer and what questions do they ask before contacting you?
Which pages answer those questions directly?

Map those questions to pages first. A keyword list tells you what people type. Your page map tells you where each answer lives on your site.

Plan your URL structure early

URL slugs should be clean, descriptive, and final before development starts. Changing URLs after launch means setting up 301 redirects, updating internal links, and risking ranking drops during the transition. Get them right the first time.

Think about conversion paths, not just content

Every key page should have a clear next step. Where does a visitor go after reading your services page? Is there a logical path from a blog post to a contact form? Dead ends hurt both UX and SEO. Plan the internal linking structure alongside the content map.

Phase 2: Build with crawlability and structure in mind

Get robots.txt right from the start

A clean robots.txt should allow all important pages and block only what you intend: admin panels, staging environments, and duplicate filter URLs. Run a crawl on staging using Screaming Frog or Ahrefs before launch to catch anything that got accidentally blocked.

Also check your robots.txt to make sure important AI crawlers are not blocked. These entries are commonly allowed:

User-agent: GPTBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

If your site is client-side rendered (Next.js without SSR, plain React), these bots often see a blank page. Consider server-side rendering or static generation for content-heavy routes.

Every template ships with metadata and one H1

Do not hand-tune metadata page by page after launch. Set the pattern at the template level:

A unique, descriptive <title> and <meta description> on every template
One <h1> per page that matches the page intent
Logical <h2> and <h3> structure below it
Internal links to related services, proof pages, and contact where they help the reader

Consistent patterns across templates scale better than perfecting one page at a time.

Add structured data where it actually matches your content

Useful schema types for most business and dev-focused sites:

Organization: name, logo, contact details, social profiles
Service: what you offer and who it is for
FAQPage: common questions with direct answers (AI tools like Perplexity and ChatGPT pull from this heavily)
BreadcrumbList: helps search engines understand your site hierarchy

Only mark up content that actually exists on the page. Do not add schema just to have it.

Put FAQ blocks on key pages

Clear question-and-answer blocks near the bottom of service and landing pages do two things: they answer real buyer questions, and they feed structured data that AI tools cite when users search for services like yours.

Phase 3: Performance and trust signals before go-live

Core Web Vitals on your primary templates

Test LCP, INP, and CLS on mobile for your homepage, service pages, and contact page before launch. The usual culprits on business sites:

Uncompressed hero images (serve WebP, compress to under 200KB)
Render-blocking fonts
Tag managers and chat widgets loaded in the <head>
Layout shifts from embeds or ads loading late

Run Lighthouse on staging. Do not wait for real traffic to discover a 4MB hero image.

Mobile layout and clear next steps

Most B2B research starts on a phone, even when the deal closes on desktop. Check tap targets, readable body text, form usability, and focus states. Every service page should make the next action obvious.

Set up Search Console and Analytics before launch

This is one step many teams overlook. Set up Google Search Console, verify ownership, and prepare your sitemap before launch so you can submit it as soon as the production site goes live. This helps search engines discover and crawl your website sooner after launch.

Test that Analytics events fire correctly on staging too. A site that launches with broken event tracking is flying blind from the start.

The pre-launch checklist

Before hitting publish on any new site, run through this:

[ ] Search Console verified, sitemap submitted
[ ] Analytics tested on staging, events firing correctly
[ ] robots.txt reviewed, nothing important blocked, AI crawlers allowed
[ ] All templates have unique title tags and meta descriptions
[ ] One <h1> per page, logical heading structure below it
[ ] Schema markup added for Organization, Service, FAQ where relevant
[ ] Core Web Vitals passing on mobile (Lighthouse score)
[ ] Internal links connecting key pages and guiding to next steps
[ ] URL slugs finalized and clean
[ ] FAQ blocks on key service pages

When does SEO get complicated enough to need a specialist?

For most straightforward marketing sites, a developer who understands the above can cover the technical foundations. You may want dedicated SEO support when:

Your stack is JavaScript-heavy and rendering behavior is unclear
You have a complex information architecture with hundreds of pages
You are launching in a competitive niche where content strategy matters from day one
The timeline is tight and there is no room to fix crawl issues after launch

One thing worth knowing

Fixing SEO after launch is absolutely possible. But the teams that get organic visibility fastest are the ones that treated plan, build, and measure as build-week decisions rather than a follow-up task.

If you want a deeper breakdown of how this works in practice, this pre-launch SEO guide for new websites covers the full process including the planning phase most developers skip entirely.

What did your last launch get right on the SEO side? Drop it in the comments.

6 Things We Learned the Hard Way About Laravel Performance in Real Projects

Jasmine Dueñas — Tue, 05 May 2026 05:36:24 +0000

In this article, I'll share six Laravel performance lessons we learned from building real client systems, including how Eloquent queries, caching, code structure, deadlines, and communication affected the way we build and maintain applications.

We didn't notice anything wrong at first.

The app worked, responses were fine, and everything looked clean during development.

Then real users started using it every day.

APIs slowed down, dashboards took longer to load, and small inefficiencies started to add up.

That's when we realized most of the issues were not infrastructure related. They were coming from how we were building things in Laravel.

I've been working on Laravel projects with a small team at Spice Factory Philippines, mostly working with companies that rely on these systems for daily operations, and these are some of the things we learned the hard way.

1. Eloquent is easy to use, but also easy to abuse

Eloquent makes it very easy to move fast, especially early on.

The problem is, it also makes it easy to ignore what's happening underneath.

We ran into cases where endpoints were slower than expected because of:

relationships being loaded inside loops
too many queries being executed
returning more data than needed

Fixing it wasn't complicated. Just being more intentional with queries already helped.

$users = User::with('roles')->get();

Once we started checking queries more carefully, performance improved right away.

2. Most slow APIs are not infrastructure problems

At one point, we thought we needed to upgrade servers.

It turned out the issue was in our own code.

Some of the common problems we saw:

missing database indexes
repeated queries for the same data
unnecessary data being fetched

After cleaning those up, response times improved without changing infrastructure.

That was a good reminder that optimization usually starts at the application level.

3. Caching felt optional until it wasn't

During development, everything worked fine without caching.

Once real usage kicked in, especially on dashboards and reports, the difference became obvious.

We started adding caching in places where data didn't need to be recalculated every time.

Cache::remember('dashboard_stats', 60, function () {
    return $this->getStats();
});

Even simple caching made a noticeable impact on performance and reduced database load.

4. Structure matters when the project grows

For smaller features, putting logic in controllers worked fine.

As the system grew, it became harder to manage and reason about.

We didn't do a full rewrite. It was more gradual.

Whenever something started to feel messy, we moved logic into services or broke things into smaller pieces.

That made the codebase easier to maintain, especially when multiple developers were working on it.

5. Deadlines change how you think about "clean code"

In personal projects, you can spend time getting everything just right.

In client work, timelines are part of the equation.

Sometimes the focus is:

getting something working
making sure it's stable
improving it later when there's time

You start thinking in terms of trade-offs instead of trying to make everything perfect from the start.

6. Communication saves more time than clever code

One thing that made a bigger difference than expected was communication.

A lot of issues we dealt with were not technical. They came from unclear requirements or assumptions.

Taking time to clarify things early helped avoid rework later.

In many cases, being clear saved more time than trying to come up with a more complex solution.

What we learned from all this

Working on real client systems changed how we approach Laravel projects.

You start paying attention to things that don't always show up in tutorials like performance, structure, and communication.

We're still figuring things out as we go, but these are the ones that made the biggest difference so far.

If you're working on similar projects, curious what things stood out for you once you moved from tutorials to real systems.

If you're curious how we approach building and maintaining systems for real-world use, you can check what we do here:

Web, System & Mobile Development | Spice Factory PH

Web development, mobile apps, and custom systems from strategy to launch. Agile delivery with modern stacks and engineer-led collaboration.

spice-factory.ph