DEV Community: Moniruzzaman Saikat

Essential Sections and Pages Every Real Estate Website Template Should Have

Moniruzzaman Saikat — Mon, 24 Aug 2026 20:01:38 +0000

A real estate website template has a different job from a normal corporate website.

A corporate website may succeed by explaining the company, presenting a few services, and providing a contact form. A real estate website has to support a much more complex user journey.

Visitors need to search properties, compare listings, understand locations, evaluate prices, inspect photos and amenities, contact agents, save properties, and sometimes submit their own listings.

That means a strong real estate template cannot be designed as:

Homepage + About + Contact + a few property cards

It needs to behave more like a small property marketplace.

Whether you are creating a template for ThemeForest, Creative Market, your own marketplace, or a client project, the right page architecture matters almost as much as the visual design.

In this article, we will break down the essential sections, pages, components, user flows, and production considerations that a serious real estate template should include.

1. Start With the User Journeys

Before designing pages, identify what people actually want to accomplish.

A real estate website typically serves several different users.

Property buyers

They want to:

Search properties
Filter by location
Filter by price
Filter by property type
Compare properties
View photos
Check amenities
See property details
Contact the agent
Schedule a viewing
Save properties

Renters

Their needs are similar, but rental-specific information becomes more important:

Monthly rent
Deposit
Lease duration
Furnishing status
Availability date
Utilities
Pet policies
Parking
Nearby transportation

Property owners

Depending on the business model, owners may want to:

Submit properties
Edit listings
Upload images
Manage inquiries
View listing performance

Agents

Agents may need:

Public profiles
Their property listings
Contact information
Social links
Reviews
Inquiry management
Dashboard tools

Agencies

An agency may need:

Company profile
Team members
Service areas
Properties
Reviews
Contact information

Once these journeys are understood, the required pages become much easier to define.

Core Public Pages

2. Homepage

The homepage is not just a marketing landing page.

For most real estate websites, it should immediately help users start discovering properties.

The most important homepage sections are usually the following.

Hero Section

The hero should communicate the website's purpose immediately.

A typical structure could be:

Find a Place You'll Love

Buy | Rent | Commercial

[Location]
[Property Type]
[Price Range]

[Search Properties]

The hero may include a background image, featured property, city skyline, architecture photography, or a cleaner split layout.

The important part is not the image.

The important part is the search experience.

Useful hero search fields

Depending on the template:

Location
City
Neighborhood
Property type
Buy or rent
Minimum price
Maximum price
Bedrooms
Property ID

Do not overload the hero with every possible filter.

Advanced filters belong on the property search page.

Property Type Categories

Users should be able to quickly browse by property type.

Typical categories include:

Apartment
House
Villa
Office
Commercial
Land
Studio
Condo
Townhouse
Warehouse

Each category can display:

Icon
Image
Number of available properties
Short description

For example:

Apartments
1,240 properties

This section works particularly well near the beginning of the homepage.

Featured Properties

A strong real estate homepage almost always needs a featured listings section.

Property cards should provide enough information for users to make an initial decision without opening every property.

A good property card may include:

Property Image

FOR SALE

Modern Family Villa
Gulshan, Dhaka

৳3.2 Crore

4 Beds
3 Baths
2,400 sq ft

♡ Save

Additional metadata could include:

Featured badge
Verified badge
New listing badge
Property type
Price per square foot
Agent avatar
Date listed

The card design should remain visually clean despite the amount of information.

Properties for Sale

If the platform supports both rental and sales listings, separating them on the homepage can make discovery easier.

Example:

Properties for Sale

Apartment in Dhanmondi
Villa in Bashundhara
House in Uttara
Commercial Space in Banani

View All Properties

Properties for Rent

Rental listings deserve their own section when rentals are a major part of the platform.

Price formatting should clearly communicate the billing period:

৳45,000 / month

rather than simply:

৳45,000

Small details like this make a template feel like it was actually designed for real estate.

3. Location-Based Discovery

Location is arguably one of the most important dimensions of real estate.

Users often search by geography before considering the exact property.

A template should support sections like:

Explore Popular Locations

For example:

Gulshan
145 Properties

Banani
89 Properties

Dhanmondi
163 Properties

Bashundhara
217 Properties

Visually, these can be displayed as:

Image cards
Large editorial tiles
Compact cards
Map-based elements
Horizontal sliders

Location pages should also be supported deeper in the template.

4. Featured Cities or Neighborhoods

For larger real estate platforms, property location may have multiple levels:

Country
→ City
→ Area
→ Neighborhood

A location discovery section might therefore present major cities:

Dhaka
Chattogram
Sylhet
Rajshahi
Khulna

Or neighborhoods:

Gulshan
Banani
Uttara
Dhanmondi
Mirpur

A good template should make it possible to adapt the same component to either model.

5. Recommended Properties

A recommendation section gives the homepage a more marketplace-oriented feel.

Examples:

Recommended for You

Popular Near You

Recently Added

Best Value Properties

New Developments

In a static HTML template, these recommendations do not need actual personalization.

You are designing the interface that a backend system could eventually populate dynamically.

6. Property Search Page

This is one of the most important pages in the entire template.

If this page is weak, the real estate template will feel incomplete no matter how good the homepage looks.

A property search page usually needs:

Header

Breadcrumb / Page Title

Search Bar

Filter Sidebar or Filter Toolbar

Active Filters

Results Count

Sort Control

Property Results

List / Grid Toggle

Map Toggle

Pagination

Footer

Search Filters

This is where the template needs to become domain-specific.

Common filters include:

Transaction type

Buy
Rent

Property type

Apartment
House
Villa
Studio
Commercial
Office
Land

Location

City
Area
Neighborhood
ZIP / Postal Code

Price

Minimum Price
Maximum Price

or a range slider.

Bedrooms

Any
1+
2+
3+
4+
5+

Bathrooms

Similar to bedrooms.

Property size

Minimum Area
Maximum Area

Amenities

For example:

Parking
Swimming Pool
Gym
Garden
Balcony
Elevator
Security
Air Conditioning
Furnished
Pet Friendly

Property status

Available
Sold
Rented
Under Construction

Listing date

Useful for finding recent listings.

Active Filter Chips

Once filters have been applied, users should be able to see and remove them easily.

Example:

Gulshan ×
Apartment ×
3+ Bedrooms ×
Under ৳2 Crore ×

Clear All

This is a small component, but it significantly improves usability.

7. Property Listing Grid Page

Real estate templates often benefit from having multiple listing layouts.

At minimum, include:

Property Grid
Property List

The grid layout works well for visual browsing.

The list layout can provide more information without opening the property page.

Grid View

Typical structure:

[Image]

FOR SALE

Luxury Apartment
Gulshan 2, Dhaka

৳2.8 Crore

3 Beds | 3 Baths | 1,950 sq ft

List View

A list item may show:

[Large Image]

Luxury Apartment in Gulshan

Gulshan 2, Dhaka

Beautiful three-bedroom apartment with
modern interiors and excellent city access.

3 Beds
3 Baths
1,950 sq ft

৳2.8 Crore

View Details

Supporting both interfaces makes a commercial template significantly more complete.

8. Map Search Page

Modern property platforms frequently combine listings with maps.

A useful layout might be:

----------------------------------
| Property Results |             |
|                  |     Map     |
| Property Card    |             |
| Property Card    |             |
| Property Card    |             |
----------------------------------

On desktop:

40% listing panel
60% map

or:

50% listings
50% map

On mobile, the layout can switch between:

List
Map

using tabs or buttons.

Even if your static template uses a placeholder map, designing this page demonstrates that the template is prepared for a real property platform.

9. Property Detail Page

This is probably the most important page to design carefully.

A property detail page has a large amount of information, and poor hierarchy can make it overwhelming.

The page should generally progress from visual information to essential facts to detailed information.

Property Gallery

Photography sells real estate.

The gallery needs more attention than a standard e-commerce gallery.

Good options include:

Large main photo + 4 supporting images

or:

Large gallery carousel

Include a control like:

View All 24 Photos

Potential additional actions:

Save
Share
Print

Property Header

Immediately below or beside the gallery, show:

Luxury Family Villa

Gulshan 2, Dhaka

FOR SALE

৳3.5 Crore

Optionally include:

Property ID: RE-10284

Property Quick Facts

Important characteristics should be visually scannable.

For example:

Bedrooms
4

Bathrooms
3

Area
2,450 sq ft

Garage
2

Year Built
2024

Icons work well here.

10. Property Overview

A compact overview can include:

Property ID
Property Type
Status
Bedrooms
Bathrooms
Garage
Year Built
Size
Lot Size

A grid format works well for this information.

11. Property Description

Listings often contain longer descriptions.

Typography needs to support several paragraphs comfortably.

For example:

About This Property

This modern four-bedroom residence combines
spacious living areas with contemporary architecture...

Avoid extremely narrow text columns or oversized typography.

Property descriptions need to remain readable.

12. Amenities and Features

Amenities are essential.

A typical section could include:

✓ Air Conditioning
✓ Swimming Pool
✓ Security
✓ Parking
✓ Elevator
✓ Balcony
✓ Gym
✓ Garden
✓ Backup Generator
✓ High-Speed Internet

Use a multi-column layout on desktop.

13. Floor Plans

Professional real estate templates should include a floor plan section.

Each floor plan may display:

Ground Floor
1,200 sq ft

Bedrooms: 2
Bathrooms: 2

[Floor Plan Image]

For multiple floors, an accordion works well:

Ground Floor
First Floor
Second Floor

14. Video Tour

Some property platforms include:

Property Video

The interface may support:

YouTube
Vimeo
Self-hosted video
Video thumbnail with modal

Even when not required by every project, having the component makes the template more versatile.

15. Virtual Tour

Higher-end real estate platforms increasingly use virtual tours.

Your template could provide a dedicated block:

360° Virtual Tour

Explore the property from anywhere.

[Start Virtual Tour]

The developer purchasing your template could later integrate Matterport or another virtual tour provider.

16. Property Location

The detail page needs a location section.

Typical information:

Address
Road 54, Gulshan 2, Dhaka

City
Dhaka

Area
Gulshan

Postal Code
1212

Followed by a map.

Exact addresses may sometimes be hidden for privacy, so templates should support approximate location information too.

17. What's Nearby

Nearby places can make a property detail page much more useful.

Example:

Nearby Places

School          0.4 km
Hospital        1.2 km
Supermarket     0.6 km
Metro Station   0.8 km
Restaurant      0.3 km
Park            1.1 km

This section adds practical context rather than simply presenting property specifications.

18. Agent Contact Card

The agent contact component is critical.

It could include:

[Agent Photo]

Sarah Ahmed
Senior Property Consultant

Phone
Email
WhatsApp

[Send Message]
[Schedule Viewing]

On desktop, this card can be placed in a sticky sidebar while scrolling through property details.

That keeps the conversion action available throughout the page.

19. Property Inquiry Form

A simple inquiry form may contain:

Name
Email
Phone
Message

I'm interested in this property.

[Send Inquiry]

Prefilling the message with the property name or ID is useful.

For example:

Hi, I'm interested in Property RE-10284.
Please contact me with more information.

20. Schedule a Viewing

A dedicated viewing request interface can provide:

Choose Date

Choose Time

Your Name
Email
Phone

[Schedule Viewing]

A well-designed template can show this as:

Modal
Sidebar form
Dedicated page
Inline form

21. Mortgage Calculator

A mortgage calculator is another valuable real estate component.

Fields can include:

Property Price
Down Payment
Interest Rate
Loan Term

Output:

Estimated Monthly Payment
৳128,450

Even a front-end demonstration makes the template feel much more complete.

22. Similar Properties

At the bottom of the detail page, show related listings.

For example:

Similar Properties

4 Bedroom Villa
Gulshan
৳3.2 Crore

Luxury Apartment
Banani
৳2.9 Crore

This keeps users exploring instead of reaching a dead end.

23. Recently Viewed Properties

For larger templates, a recently viewed section is another useful marketplace component.

It could appear:

At the bottom of the property page
On the homepage
Inside the user dashboard

The static version can demonstrate the UI using localStorage.

Agent Pages

24. Agents Directory

A real estate marketplace often has multiple agents.

Create a dedicated page such as:

Our Agents

Agent cards could display:

[Photo]

John Smith
Property Consultant

24 Properties

Phone
Email

View Profile

Optional filters:

Location
Specialization
Agency
Language

25. Agent Detail Page

Each agent needs a proper profile page.

Recommended sections:

Agent Profile Header

Photo
Name
Position
Agency
Phone
Email
Social Links
WhatsApp

About Agent

Specializations

Service Areas

Agent Properties

Reviews

Contact Form

An experienced agent may also have:

Years of Experience
Properties Sold
Active Listings
Client Rating

Agency Pages

26. Agencies Directory

If the system supports multiple real estate agencies, create an agency directory.

Agency cards may show:

Agency Logo

Urban Homes Realty

Dhaka, Bangladesh

32 Agents
148 Properties

View Agency

27. Agency Profile Page

The agency page may include:

Logo

Agency Name

About Agency

Address

Contact Details

Social Links

Agents

Available Properties

Reviews

Office Locations

This is especially useful for multi-vendor property marketplace templates.

Location Pages

28. City Detail Page

A dedicated city page creates a stronger browsing experience.

For example:

Properties in Dhaka

Possible sections:

City Overview

Property Statistics

Popular Neighborhoods

Properties for Sale

Properties for Rent

Local Agents

Map

Area Guide

FAQ

From a development perspective, this page can later become useful for search engine landing pages as well.

29. Neighborhood or Area Detail Page

Users often care about neighborhoods more than entire cities.

A neighborhood page could include:

Living in Gulshan

Average Property Price

Available Properties

Schools

Hospitals

Restaurants

Transportation

Lifestyle

Map

Nearby Areas

This type of page can make a real estate platform significantly richer.

Property Submission

30. Add Property Page

If agents or property owners can submit listings, this is essential.

Instead of one giant form, use structured steps.

For example:

Step 1
Basic Information

Step 2
Price and Location

Step 3
Property Details

Step 4
Amenities

Step 5
Media

Step 6
Review and Publish

Basic Property Information

Fields might include:

Property Title
Description
Property Type
Listing Type
Property Status

Pricing

Price
Price Prefix
Price Suffix

This supports formats like:

Starting from ৳75 Lac

or:

৳40,000 / month

Property Details

Bedrooms
Bathrooms
Garage
Area
Lot Size
Year Built

Location

Country
City
Area
Address
Postal Code
Latitude
Longitude

Amenities

Checkboxes work well:

Pool
Gym
Security
Parking
Elevator
Balcony
Garden
Furnished

Media

Allow:

Property Images
Featured Image
Floor Plans
Property Video URL
Virtual Tour URL

A drag-and-drop uploader is a good UI choice here.

Authentication Pages

31. Login

Real estate platforms often have:

Login
Register
Forgot Password

A clean login page should support:

Email
Password
Remember Me

Potential social login placeholders:

Continue with Google
Continue with Facebook

32. Registration

Depending on the platform, registration might allow different account types:

Buyer
Property Owner
Agent
Agency

The role selection should be clearly designed.

User Dashboard

33. Dashboard Overview

A professional template benefits greatly from dashboard pages.

The dashboard overview might show:

Active Listings
Pending Listings
Total Views
Saved Properties
Messages
Inquiries

Charts could display listing views or inquiries over time.

34. My Properties

Users should be able to manage their listings.

A property management table might include:

Property
Date
Status
Views
Price
Actions

Actions:

Edit
Delete
View
Duplicate

35. Add New Property

The dashboard version can reuse the property submission form.

Keeping both frontend submission and dashboard submission patterns consistent improves the design system.

36. Saved Properties

Users need somewhere to manage favorites.

Example:

Saved Properties

[Property Card]
[Property Card]
[Property Card]

Include:

Remove
View Property
Contact Agent

37. Property Comparison

Comparison functionality is particularly useful for buyers.

Users may compare:

Property A
Property B
Property C

Across attributes such as:

Feature	Property A	Property B	Property C
Price	৳2.4 Cr	৳2.8 Cr	৳2.6 Cr
Bedrooms	3	4	3
Bathrooms	3	4	3
Area	1,850 sq ft	2,300 sq ft	2,050 sq ft
Parking	1	2	2
Furnished	Yes	No	Yes

This gives the template another meaningful user flow.

38. Messages

If the marketplace supports internal communication, provide a messages interface.

Typical layout:

-------------------------------
| Conversations | Chat        |
|               |             |
| Sarah Ahmed   | Messages    |
| David Karim   |             |
| Urban Realty  |             |
-------------------------------

A simpler template can skip live chat but still demonstrate an inbox UI.

39. Inquiries

Agents need to manage property inquiries.

For example:

Property
Customer
Phone
Date
Status

Inquiry statuses might include:

New
Contacted
Viewing Scheduled
Closed

40. Profile Settings

Account settings should include:

Profile Information
Photo
Name
Phone
Email
Address
Social Profiles
Password
Notification Preferences

Agent accounts may also include:

Bio
License Number
Specialization
Service Areas
Agency

Supporting Marketing Pages

41. About Us

The About page should not be overly generic.

For a real estate business, useful sections include:

Company Story

Mission

Why Choose Us

Statistics

Team

Locations

Testimonials

CTA

Statistics might include:

5,000+
Properties Listed

2,400+
Happy Clients

150+
Professional Agents

12
Cities Covered

42. Services Page

Real estate businesses often offer more than property listings.

Services might include:

Property Buying
Property Selling
Property Rental
Property Management
Commercial Real Estate
Investment Consulting
Property Valuation
Mortgage Assistance

Each service can link to a service detail page.

43. Service Detail Page

A scalable template should include at least one example service detail page.

Structure:

Service Header

Overview

How It Works

Benefits

Process

Related Services

FAQ

Contact CTA

44. Blog Page

Real estate businesses rely heavily on educational and market content.

The blog page might include categories such as:

Buying Guides
Selling Guides
Investment
Market Trends
Home Improvement
Neighborhood Guides
Real Estate News

45. Blog Detail Page

A complete article page should include:

Title
Category
Author
Date
Featured Image
Article Content
Tags
Share Buttons
Author Box
Related Posts
Comments

Typography matters heavily here.

Many HTML templates build impressive landing pages but neglect long-form content styles.

Make sure headings, lists, quotes, images, tables, code-free rich text, and spacing all work properly.

46. Contact Page

The contact page should contain more than a form.

Useful information includes:

Office Address
Phone
Email
Working Hours
WhatsApp
Map

Form fields:

Name
Email
Phone
Subject
Message

If the company operates multiple branches, office cards can also be useful.

47. FAQ Page

Real estate transactions create many repetitive questions.

FAQ categories might include:

Buying
Selling
Renting
Property Listings
Agents
Payments
Accounts

An accordion layout works well.

48. Testimonials or Reviews

Testimonials may appear on several pages, but a dedicated review component should exist in the design system.

Reviews could show:

Client Photo

"Excellent service..."

Client Name
Property Buyer

★★★★★

Avoid filling every page with testimonial sliders. Use them where they help build trust.

49. Pricing Page

If the platform charges property owners or agencies for listings, a pricing page becomes essential.

Example plans:

Basic

5 Property Listings
30 Days
Email Support

$19

Professional

25 Property Listings
Featured Listings
Analytics
Priority Support

$49

Agency

Unlimited Listings
10 Agent Accounts
Advanced Analytics
Premium Support

$99

50. Membership or Subscription Pages

A marketplace template may include:

Membership Plans
Checkout
Payment Success
Payment Failed
Billing History

These pages are not necessary for every real estate theme, but they can significantly increase the scope of a marketplace-oriented template.

Utility Pages

51. 404 Page

Never forget the 404 page.

Keep it useful:

Property Not Found

The page you're looking for may have moved
or is no longer available.

[Browse Properties]
[Return Home]

52. Empty States

Templates often overlook empty states.

You should intentionally design states such as:

No properties found.

You haven't saved any properties yet.

No messages available.

No listings match your filters.

Then provide useful actions:

Clear Filters
Browse Properties
Add Property

Good empty states make the dashboard and marketplace interfaces feel much more realistic.

53. Search No-Results Page

This deserves special treatment.

Instead of displaying:

0 Results

show:

No properties match your search.

Try adjusting:
• Location
• Price range
• Property type
• Bedroom count

[Clear Filters]

You might also show:

Recently Added Properties

below the message.

Shared Components Every Real Estate Template Needs

Pages are only one side of the template.

A strong template also needs a consistent component system.

Header

Several header variations may be useful.

Standard header

Logo
Buy
Rent
Agents
Agencies
Blog
Contact

Sign In
Add Property

Transparent header

Useful over hero images.

Dashboard header

Usually simpler and more application-focused.

The important point is that the header should fit the product rather than blindly reusing a generic SaaS navigation.

54. Mega Menu or Property Navigation

A larger real estate platform may need structured navigation.

For example:

Buy
  Apartments
  Houses
  Villas
  Commercial
  Land

Rent
  Apartments
  Houses
  Offices
  Short-Term Rentals

Explore
  Cities
  Neighborhoods
  Agents
  Agencies

A mega menu is useful only when the information architecture actually requires it.

55. Mobile Navigation

Real estate templates have many filters and navigation items, so mobile behavior needs special attention.

The mobile navigation should support:

Menu
Search
Saved
Profile

For mobile-heavy property marketplaces, a bottom navigation can also work:

Home
Search
Saved
Messages
Profile

56. Breadcrumbs

Real estate websites often have deep navigation.

Breadcrumbs help users understand context:

Home
/
Properties
/
Dhaka
/
Gulshan
/
Luxury Family Villa

They are especially useful on:

Property detail
Agent detail
Agency detail
City pages
Neighborhood pages
Blog posts

57. Property Cards

Property cards are one of the most important components in the entire design system.

Create several states:

Default
Featured
For Sale
For Rent
Sold
New
Verified
Saved

Card interactions should remain consistent.

Do not create completely different property card styles in every section just for visual variety.

Variation should come from section composition, not from abandoning the design system.

58. Agent Cards

Create reusable agent components with:

Photo
Name
Position
Listings Count
Phone
Social Links
Profile CTA

59. Location Cards

Support multiple forms:

Large Image Card
Compact City Card
Neighborhood Card
Text-Based Location List

Again, variation is useful as long as the design language remains consistent.

60. Search Component

A property search component should work in several contexts.

For example:

Homepage Search
Listing Page Search
Mobile Search
Compact Header Search
Map Search

The underlying form language should feel related across all versions.

61. Filter Components

Reusable filter elements should include:

Checkbox
Radio
Select
Range
Location Select
Bedroom Selector
Amenity Selector
Expandable Filter Group

Mobile filters should normally open inside an offcanvas panel or full-screen overlay.

62. Sort Controls

Property results typically require sorting.

Common options:

Newest
Oldest
Price: Low to High
Price: High to Low
Most Popular
Featured

63. Pagination

Provide standard pagination:

←
1
2
3
4
...
12
→

Infinite scrolling may work for some products, but pagination remains a safer default template component.

64. Favorite or Save Interaction

Property cards and detail pages should support a save icon.

Usually:

♡

becomes:

♥

after activation.

For a static template, JavaScript can persist favorites using localStorage.

65. Share Property

A share component might include:

Copy Link
Facebook
LinkedIn
WhatsApp
Email

Avoid displaying every social network ever created.

Use the ones relevant to the intended market.

66. Status Badges

Reusable property badges might include:

FOR SALE
FOR RENT
FEATURED
NEW
VERIFIED
SOLD
RENTED

Keep colors consistent across the entire template.

67. Forms and Validation States

Design more than the default form state.

Your component system should support:

Default
Focused
Filled
Disabled
Error
Success

For example:

Email Address
john@example.com

Please enter a valid email address.

A template feels much more polished when validation states are considered.

Real Estate Template Architecture

If you are building the template itself, it helps to think in page groups.

A good directory structure might conceptually look like:

Home

Properties
  Property Grid
  Property List
  Map Search
  Property Details
  Compare

Locations
  Cities
  City Details
  Neighborhood Details

Agents
  Agents
  Agent Details

Agencies
  Agencies
  Agency Details

Submit Property

Dashboard
  Overview
  Properties
  Add Property
  Favorites
  Messages
  Inquiries
  Profile

Company
  About
  Services
  Service Details
  Pricing
  Contact
  FAQ

Blog
  Blog Grid
  Blog Details

Authentication
  Login
  Register
  Forgot Password

Utility
  404

This is much closer to a complete real estate product than simply shipping ten unrelated landing pages.

Homepage Section Order

There is no universal homepage structure, but a good starting sequence is:

Header

Hero + Property Search

Property Types

Featured Properties

Popular Locations

Properties for Sale

Promotional CTA

Properties for Rent

Why Choose Us

Featured Agents

Market Statistics

Testimonials

Latest Articles

Newsletter

Footer

You should not mechanically use every section.

Choose sections based on the template's positioning.

A luxury property template might rely heavily on editorial photography.

A marketplace might emphasize search and filters.

An agency template might emphasize agents and services.

A rental platform might prioritize availability, map search, and neighborhoods.

What Makes a Real Estate Template Feel Generic?

Many real estate templates technically include enough sections but still feel generic.

The reason is usually that the template was designed from a generic landing-page system instead of from real estate workflows.

For example:

Hero
Features
Statistics
Cards
Testimonials
Blog
CTA
Footer

That structure could describe almost any website.

A real estate template should visibly contain domain-specific interfaces such as:

Property Search
Location Search
Bedroom Filters
Price Filters
Property Galleries
Amenities
Floor Plans
Agent Profiles
Map Search
Mortgage Calculator
Viewing Requests
Saved Properties
Comparison
Property Submission

These components are what make the product clearly belong to the real estate industry.

Do Not Make Every Page Look the Same

Consistency does not mean duplication.

A common template-generation mistake is using:

Breadcrumb
Title
Three-column cards
CTA
Footer

on almost every page.

A stronger system changes composition based on purpose.

For example:

Property listing

Filters + Results

Property detail

Gallery + Property Information + Sticky Agent

Agent profile

Profile + Bio + Listings

City page

Location Hero + Market Information + Properties

Dashboard

Sidebar + Statistics + Management Tables

Blog

Editorial Content Layout

Same typography, spacing, buttons, borders, colors, and component language.

Different page composition.

That is how a multi-page template feels coherent without becoming repetitive.

Responsive Design Is Especially Important

Real estate users frequently browse properties from phones.

That means responsive behavior should not be an afterthought.

On mobile:

Property filters

Move into:

Filter

button opening an offcanvas panel.

Map search

Provide:

List | Map

toggle.

Property gallery

Convert the image grid into a carousel or simplified gallery.

Agent sidebar

Move below the main property information or convert it into a sticky bottom CTA.

For example:

Call
WhatsApp
Message

Comparison table

Allow horizontal scrolling or use vertically stacked property comparisons.

Dashboard

Collapse the sidebar into a menu.

A real estate template that looks excellent on desktop but becomes awkward when filtering properties on mobile is not production-ready.

Performance Matters

Real estate websites are image-heavy.

A single property can easily include twenty or more photos.

If the template ignores performance, the actual application built from it may become extremely slow.

Use:

<img
    src="property.jpg"
    alt="Modern apartment in Gulshan"
    loading="lazy"
>

Use appropriately sized images rather than downloading a 4K photo and rendering it inside a 350-pixel card.

Modern formats such as WebP or AVIF can also reduce image weight significantly.

Keep Property Card Images Consistent

Image consistency has a large impact on perceived quality.

Define predictable aspect ratios.

For example:

.property-card__media {
    aspect-ratio: 4 / 3;
    overflow: hidden;
}

.property-card__media img {
    width: 100%;
    height: 100%;
    object-fit: cover;
}

Without this, property cards become uneven whenever agents upload images with different dimensions.

Accessibility

A professional template should also account for accessibility.

Examples include:

Real labels for form inputs
Keyboard-accessible dropdowns
Visible focus states
Alternative text for property images
Accessible modal dialogs
Sufficient color contrast
Semantic headings
Proper buttons instead of clickable <div> elements

For icon-only buttons such as favorites:

<button aria-label="Save property">
    <i class="fa-regular fa-heart"></i>
</button>

This is better than a clickable icon with no semantic meaning.

SEO-Friendly Page Architecture

Real estate websites can generate a large number of indexable pages.

Potential URL structures might look like:

/properties

/properties/for-sale

/properties/for-rent

/properties/apartments

/properties/villas

/location/dhaka

/location/dhaka/gulshan

/property/luxury-villa-gulshan

/agents

/agents/sarah-ahmed

/agencies

/blog

Even if you are building only a frontend template, designing around clean content relationships makes backend integration easier later.

Use Realistic Demo Data

Demo content strongly affects how professional a template feels.

Avoid property names such as:

Property One
Property Two
House Example
Beautiful Home

Use realistic examples:

Contemporary 3-Bedroom Apartment in Gulshan

Lakeview Family Residence in Dhanmondi

Modern Commercial Office in Banani

Furnished Studio Near Uttara Metro Station

Likewise, use realistic prices, addresses, room counts, property sizes, and agent profiles.

Good demo content makes screenshots immediately more convincing.

Think Beyond the Homepage

This is probably the most important lesson when designing templates for sale.

A homepage can be visually impressive while the overall template remains weak.

Buyers evaluating a commercial real estate template will eventually ask:

How do I search properties?

What does the detail page look like?

Is there a map layout?

Does it support agents?

Can users submit properties?

Is there a dashboard?

What happens on mobile?

Are favorites supported?

Can properties be compared?

What does the empty state look like?

Your template should answer those questions visually.

Minimum Page Set

If you want a smaller but still credible real estate template, I would consider this the minimum serious page set:

01. Homepage
02. Property Grid
03. Property List
04. Map Search
05. Property Details
06. Agents
07. Agent Details
08. Locations
09. Location Details
10. Add Property
11. Favorites
12. Compare Properties
13. Login
14. Register
15. Dashboard
16. About
17. Services
18. Blog
19. Blog Details
20. Contact
21. FAQ
22. 404

That already gives developers enough building blocks to create several types of property websites.

Larger Marketplace Template

For a premium marketplace-oriented template, I would expand it to something closer to:

Home
Home Alternative

Property Grid
Property List
Map Search
Property Detail
Compare Properties

Properties for Sale
Properties for Rent

Cities
City Detail
Neighborhood Detail

Agents
Agent Detail

Agencies
Agency Detail

Submit Property

Dashboard Overview
My Properties
Add Property
Favorites
Messages
Inquiries
Profile
Settings

Pricing
Checkout
Payment Success

About
Services
Service Detail
Contact
FAQ

Blog
Blog Detail

Login
Register
Forgot Password

404

You do not necessarily need thirty completely independent designs.

Shared components can cover a large amount of this functionality.

The goal is to demonstrate a complete system.

Recommended Priority When Building the Template

If you are developing the template page by page, build the most important product flows first.

A practical order is:

1. Design System
2. Header and Footer
3. Homepage
4. Property Card
5. Property Listing
6. Filters
7. Property Detail
8. Map Search
9. Agent Pages
10. Location Pages
11. Property Submission
12. Dashboard
13. Favorites and Comparison
14. Marketing Pages
15. Blog
16. Authentication
17. Utility States
18. Mobile Refinement

This order reduces rework.

For example, once the property card is finalized, you can reuse it across:

Homepage
Search results
Agent profiles
Agency pages
City pages
Favorites
Related properties

That is much better than independently designing similar components on every page.

Final Checklist

Before calling a real estate template complete, verify that it covers the major workflows.

Discovery

[ ] Property search
[ ] Buy/rent selection
[ ] Property categories
[ ] Location browsing
[ ] Advanced filtering
[ ] Sorting
[ ] Grid/list views
[ ] Map search

Property Details

[ ] Image gallery
[ ] Price
[ ] Property specifications
[ ] Description
[ ] Amenities
[ ] Floor plans
[ ] Video or virtual tour
[ ] Location map
[ ] Nearby places
[ ] Agent information
[ ] Inquiry form
[ ] Schedule viewing
[ ] Similar properties

Users

[ ] Login
[ ] Registration
[ ] Favorites
[ ] Property comparison
[ ] Profile
[ ] Messages or inquiries

Agents and Agencies

[ ] Agent directory
[ ] Agent profile
[ ] Agency directory
[ ] Agency profile

Property Management

[ ] Add property
[ ] Edit property
[ ] My properties
[ ] Listing status
[ ] Media upload interface

Supporting Pages

[ ] About
[ ] Services
[ ] Contact
[ ] FAQ
[ ] Blog
[ ] Blog detail
[ ] Pricing if applicable
[ ] 404

UX

[ ] Responsive filters
[ ] Mobile property gallery
[ ] Empty states
[ ] Loading states
[ ] Validation states
[ ] Pagination
[ ] Breadcrumbs
[ ] Consistent badges
[ ] Accessible controls

Conclusion

A good real estate template should not simply look like a real estate website.

It should behave like the foundation of a real real estate product.

That means property discovery needs proper search and filtering. Property pages need galleries, specifications, amenities, maps, floor plans, and conversion actions. Agents and agencies need their own content hierarchy. Buyers need favorites and comparisons. Sellers need property submission and management tools.

The best templates also think beyond the obvious screens.

They account for empty results, mobile filters, saved properties, dashboards, map views, viewing requests, image performance, responsive behavior, and reusable design components.

The difference between a basic real estate HTML theme and a professional real estate template is therefore not the number of decorative homepage sections.

It is the completeness of the system.

Design the search experience first. Build strong property cards. Treat the property detail page as the central conversion page. Create reusable components. Then expand the system around buyers, renters, owners, agents, agencies, and locations.

Once those pieces work together, you are no longer designing a collection of pages.

You are designing the frontend foundation of a real estate platform.

How to Become a .NET Developer in 2026: A Practical Roadmap From Zero to Production

Moniruzzaman Saikat — Sat, 08 Aug 2026 17:51:09 +0000

Learning .NET in 2026 is not mainly about learning how to write C#.

You can understand variables, loops, classes, LINQ, and even ASP.NET Core controllers and still struggle to build a production application.

The actual job of a modern .NET developer involves much more:

C#
.NET
ASP.NET Core
HTTP and REST APIs
databases
Entity Framework Core
authentication and authorization
dependency injection
testing
logging
caching
Docker
CI/CD
cloud infrastructure
application architecture
debugging
security
performance
Git
AI-assisted development

That list can make the ecosystem look intimidating.

It does not need to be.

The mistake is trying to learn everything simultaneously.

A better approach is to learn .NET in layers and build increasingly realistic applications as your knowledge grows.

This article presents the roadmap I would follow if I were becoming a .NET developer in 2026.

First, Understand What ".NET Developer" Actually Means

.NET is not a programming language.

It is Microsoft's open-source, cross-platform development platform. C# is the language most commonly associated with it. Modern .NET applications can run on Windows, Linux, and macOS.

The ecosystem can be roughly visualized like this:

C#
 │
 ▼
.NET
 │
 ├── ASP.NET Core
 │      ├── REST APIs
 │      ├── Minimal APIs
 │      ├── MVC
 │      ├── Razor Pages
 │      ├── Blazor
 │      └── SignalR
 │
 ├── Worker Services
 │
 ├── Desktop
 │
 ├── Cloud Services
 │
 └── Other application models

If your goal is backend or full-stack software engineering, the most useful path is usually:

C#
↓
.NET
↓
ASP.NET Core
↓
SQL
↓
Entity Framework Core
↓
REST APIs
↓
Authentication
↓
Testing
↓
Architecture
↓
Docker
↓
Cloud + CI/CD

That is the path this article focuses on.

1. Start With Modern .NET, Not Old .NET Framework

One of the first sources of confusion for beginners is Microsoft's naming history.

You will encounter:

.NET Framework
.NET Core
.NET 5
.NET 6
.NET 7
.NET 8
.NET 9
.NET 10

Do not start a new learning journey with old .NET Framework tutorials unless you specifically need to maintain legacy applications.

For modern development in 2026, focus on .NET 10.

.NET 10 is an LTS release and Microsoft lists its support through November 2028. .NET 9 is an STS release supported through November 2026.

For someone learning today, that makes .NET 10 a sensible default.

Install:

.NET 10 SDK
Visual Studio 2026, JetBrains Rider, or VS Code
Git
Docker Desktop
PostgreSQL or SQL Server
an API client such as Bruno or Postman

Then verify:

dotnet --version

Create your first application:

dotnet new console -n HelloDotNet
cd HelloDotNet
dotnet run

Do this before installing twenty extensions and watching fifteen hours of tutorials.

Get something running first.

2. Learn C# Properly

C# should be your first serious investment.

C# 14 is the current C# release associated with .NET 10.

Do not rush directly into ASP.NET Core.

Framework knowledge without language knowledge creates developers who can copy code but cannot debug it.

You should become comfortable reading and writing ordinary C# before building large web applications.

Start with the fundamentals

Learn:

Variables
Data types
Operators
Conditions
Loops
Methods
Arrays
Collections
Classes
Objects
Interfaces
Enums
Exceptions
Generics
Nullable types

For example:

public class Product
{
    public int Id { get; set; }

    public required string Name { get; set; }

    public decimal Price { get; set; }

    public bool IsAvailable { get; set; }
}

Then:

var products = new List<Product>
{
    new()
    {
        Id = 1,
        Name = "Mechanical Keyboard",
        Price = 120,
        IsAvailable = true
    },
    new()
    {
        Id = 2,
        Name = "Mouse",
        Price = 45,
        IsAvailable = false
    }
};

This code is easy.

The goal is not memorization.

You should understand what is happening and be able to modify it without assistance.

3. Understand Object-Oriented Programming, But Do Not Worship It

C# is heavily object-oriented, so you need to understand:

encapsulation
abstraction
inheritance
polymorphism
interfaces
composition

But knowing the definitions is not enough.

Consider this:

public interface IPaymentService
{
    Task<PaymentResult> ChargeAsync(
        decimal amount,
        CancellationToken cancellationToken);
}

And an implementation:

public class StripePaymentService : IPaymentService
{
    public async Task<PaymentResult> ChargeAsync(
        decimal amount,
        CancellationToken cancellationToken)
    {
        // Call payment provider

        return new PaymentResult(true);
    }
}

Why use an interface?

Not simply because "SOLID says so."

Maybe because:

you have multiple payment providers
you want easier testing
the implementation belongs behind an abstraction
provider-specific code should not leak into business logic

That reasoning matters more than memorizing design principles.

Also learn when not to create abstractions.

A common junior developer mistake is turning every class into:

IFoo
Foo
IBar
Bar
IBaz
Baz

even when there is only one simple implementation and no useful boundary.

Good architecture is not measured by interface count.

4. Learn Collections, Generics, and LINQ

LINQ is one of the most important C# skills for backend development.

Suppose:

var orders = new List<Order>();

You should comfortably understand code like:

var expensiveOrders = orders
    .Where(x => x.Total > 1000)
    .OrderByDescending(x => x.Total)
    .Take(10)
    .ToList();

Learn:

Where
Select
First
FirstOrDefault
Single
SingleOrDefault
Any
All
OrderBy
OrderByDescending
GroupBy
Join
Take
Skip
Distinct

More importantly, understand deferred execution.

This:

var query = products.Where(x => x.Price > 100);

does not always mean the same thing depending on whether products is an in-memory collection or an IQueryable<T> connected to Entity Framework.

That distinction becomes extremely important later.

5. Learn Async/Await Early

Modern backend software spends a lot of time waiting on I/O:

database queries
HTTP APIs
file systems
message brokers
caches
cloud services

So asynchronous programming is essential.

Example:

public async Task<Product?> GetProductAsync(
    int id,
    CancellationToken cancellationToken)
{
    return await dbContext.Products
        .FirstOrDefaultAsync(
            product => product.Id == id,
            cancellationToken);
}

Understand:

Task
Task<T>
async
await
CancellationToken

Do not memorize async and await as magic keywords.

Understand why asynchronous I/O helps a server avoid unnecessarily blocking threads while waiting for external operations.

Also learn common mistakes such as:

.Result
.Wait()

and unnecessary patterns such as:

return await Task.FromResult(value);

You should eventually be able to recognize async code that technically compiles but provides no actual benefit.

6. Understand .NET Before ASP.NET Core

Once your C# fundamentals are reasonable, understand what the .NET platform provides.

Learn the basic ideas around:

CLR
Garbage collection
Assemblies
NuGet
SDK
Runtime
JIT compilation
Configuration
Dependency injection
Logging
Hosting

You do not need CLR internals at the beginning.

But you should understand the relationship:

Your C# Code
    ↓
Compiler
    ↓
Intermediate Language
    ↓
.NET Runtime
    ↓
Execution

Understand project files too.

A modern .csproj might look like:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

</Project>

Many beginners ignore the project file entirely.

Do not.

Eventually you will need it for:

target frameworks
package references
build configuration
analyzers
compiler options
publishing behavior

7. Learn HTTP Before You Learn ASP.NET Core Deeply

This is one of the most valuable things you can do.

Before becoming obsessed with controllers, learn HTTP.

Understand:

Request
Response
Headers
Body
Query parameters
Path parameters
Cookies
HTTP methods
Status codes
Content types
Authentication headers
CORS
Caching

Understand the difference between:

GET /api/products

and:

GET /api/products/42

and:

POST /api/products

and:

PUT /api/products/42

and:

DELETE /api/products/42

Know common status codes:

200 OK
201 Created
204 No Content

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
409 Conflict
422 Unprocessable Content

500 Internal Server Error

If HTTP is unclear, ASP.NET Core will feel like magic.

If HTTP is clear, ASP.NET Core becomes a convenient implementation framework.

8. Move Into ASP.NET Core

ASP.NET Core is the modern .NET web framework for building web applications and services, and Microsoft describes it as cross-platform, open-source, and designed for modern workloads.

ASP.NET Core includes several application models:

Web APIs
Minimal APIs
MVC
Razor Pages
Blazor
SignalR
gRPC

For backend development, start with Web APIs.

Create one:

dotnet new webapi -n Store.Api
cd Store.Api
dotnet run

Then understand the generated application rather than blindly deleting everything.

9. Understand Program.cs

Modern ASP.NET Core applications are configured primarily from Program.cs.

Example:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();

builder.Services.AddOpenApi();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
}

app.UseHttpsRedirection();

app.MapControllers();

app.Run();

This small file contains several major concepts.

You need to understand:

Application builder
Dependency injection container
Service registration
Middleware pipeline
Endpoint routing
Environment configuration
Application startup

Microsoft's ASP.NET Core fundamentals documentation identifies dependency injection, configuration, and middleware among the framework's core concepts.

Spend time here.

Understanding the ASP.NET Core request pipeline will make many later concepts much easier.

10. Learn Dependency Injection

Dependency injection is built deeply into ASP.NET Core.

Example:

builder.Services.AddScoped<IProductService, ProductService>();

Then:

public class ProductsController : ControllerBase
{
    private readonly IProductService _productService;

    public ProductsController(IProductService productService)
    {
        _productService = productService;
    }
}

You should understand the major lifetimes:

Transient
Scoped
Singleton

A simplified mental model:

Transient

A new instance is created whenever requested.

Scoped

One instance generally exists for the current request scope in a typical web application.

Singleton

One instance is shared for the application lifetime.

Do not randomly choose Scoped because every tutorial does it.

Think about object lifetime and shared state.

Especially understand why injecting request-scoped dependencies into singleton services creates problems.

11. Learn Middleware

A request roughly travels through:

Client
  ↓
Middleware
  ↓
Middleware
  ↓
Middleware
  ↓
Endpoint
  ↓
Response

You might use middleware for:

exception handling
request logging
authentication
authorization
CORS
rate limiting
correlation IDs

A simple custom middleware might look like:

public class RequestTimingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<RequestTimingMiddleware> _logger;

    public RequestTimingMiddleware(
        RequestDelegate next,
        ILogger<RequestTimingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var stopwatch = Stopwatch.StartNew();

        await _next(context);

        stopwatch.Stop();

        _logger.LogInformation(
            "Request {Method} {Path} completed in {Elapsed}ms",
            context.Request.Method,
            context.Request.Path,
            stopwatch.ElapsedMilliseconds);
    }
}

Then register it:

app.UseMiddleware<RequestTimingMiddleware>();

When you understand middleware, ASP.NET Core stops feeling mysterious.

12. Controllers vs Minimal APIs

ASP.NET Core supports both controller-based APIs and Minimal APIs. .NET 10 includes continued improvements to Minimal APIs and OpenAPI support.

A controller might look like:

[ApiController]
[Route("api/products")]
public class ProductsController : ControllerBase
{
    [HttpGet("{id:int}")]
    public IActionResult Get(int id)
    {
        return Ok(new
        {
            Id = id,
            Name = "Keyboard"
        });
    }
}

A Minimal API might look like:

app.MapGet("/api/products/{id:int}", (int id) =>
{
    return Results.Ok(new
    {
        Id = id,
        Name = "Keyboard"
    });
});

Do not waste time arguing that one approach is universally better.

Minimal APIs work particularly well for smaller services and focused endpoints.

Controllers can provide useful organization for conventional API-heavy applications.

Learn both.

Then choose based on the application.

13. Learn SQL Before Hiding Everything Behind an ORM

This may be one of the most important recommendations in this article.

Do not become an Entity Framework developer who cannot write SQL.

Learn:

SELECT
INSERT
UPDATE
DELETE
JOIN
GROUP BY
ORDER BY
WHERE
HAVING
LIMIT / TOP
Subqueries
Indexes
Transactions
Constraints

Understand:

Primary keys
Foreign keys
Unique constraints
Indexes
Composite indexes
Normalization
Transactions
Isolation

Example:

SELECT
    c.id,
    c.name,
    SUM(o.total) AS total_spent
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE o.status = 'completed'
GROUP BY c.id, c.name
ORDER BY total_spent DESC;

An ORM does not eliminate databases.

It generates database operations for you.

If you cannot reason about SQL, indexes, query plans, and data relationships, you will eventually create performance problems that Entity Framework cannot magically solve.

14. Learn Entity Framework Core

Once SQL fundamentals make sense, learn EF Core.

A model:

public class Product
{
    public int Id { get; set; }

    public required string Name { get; set; }

    public decimal Price { get; set; }
}

A context:

public class ApplicationDbContext : DbContext
{
    public ApplicationDbContext(
        DbContextOptions<ApplicationDbContext> options)
        : base(options)
    {
    }

    public DbSet<Product> Products => Set<Product>();
}

Registration:

builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
    options.UseNpgsql(
        builder.Configuration.GetConnectionString("Database"));
});

Then:

var products = await dbContext.Products
    .Where(product => product.Price > 100)
    .OrderBy(product => product.Name)
    .ToListAsync(cancellationToken);

Learn:

DbContext
DbSet
Migrations
Relationships
Tracking
No-tracking queries
Eager loading
Explicit loading
Transactions
Concurrency
Indexes
Query projection

Pay special attention to:

AsNoTracking()

and projections:

var products = await dbContext.Products
    .AsNoTracking()
    .Select(product => new ProductResponse(
        product.Id,
        product.Name,
        product.Price))
    .ToListAsync(cancellationToken);

Returning entire entity graphs for every read operation is often unnecessary.

15. Stop Returning Database Entities Directly From APIs

This is a common beginner design:

[HttpGet]
public async Task<List<Product>> Get()
{
    return await dbContext.Products.ToListAsync();
}

It works.

That does not mean it should become your default design.

Your database model and public API contract serve different purposes.

Use request and response models.

public record CreateProductRequest(
    string Name,
    decimal Price);

public record ProductResponse(
    int Id,
    string Name,
    decimal Price);

Controller:

[HttpPost]
public async Task<ActionResult<ProductResponse>> Create(
    CreateProductRequest request,
    CancellationToken cancellationToken)
{
    var product = new Product
    {
        Name = request.Name,
        Price = request.Price
    };

    dbContext.Products.Add(product);

    await dbContext.SaveChangesAsync(cancellationToken);

    var response = new ProductResponse(
        product.Id,
        product.Name,
        product.Price);

    return CreatedAtAction(
        nameof(GetById),
        new { id = product.Id },
        response);
}

This separation protects your API from accidental database-model changes.

16. Learn Validation

Never assume incoming client data is valid.

At minimum, validate:

Required fields
Lengths
Ranges
Formats
Relationships
Business rules

Some validation belongs near the API boundary.

Other validation represents business rules and belongs deeper in the application.

For example:

"Email is required"

is different from:

"Customer cannot cancel an order after it has been shipped"

Do not treat those as the same kind of rule.

17. Learn Authentication and Authorization

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

You should eventually understand:

Cookies
JWT
Claims
Roles
Policies
OAuth 2.0
OpenID Connect
Refresh tokens
Identity providers

A common API configuration might include:

builder.Services.AddAuthentication(
    JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters =
            new TokenValidationParameters
            {
                ValidateIssuer = true,
                ValidateAudience = true,
                ValidateLifetime = true,
                ValidateIssuerSigningKey = true
            };
    });

Then:

[Authorize]
[HttpGet("profile")]
public IActionResult Profile()
{
    return Ok();
}

And role or policy checks:

[Authorize(Roles = "Admin")]

But do not stop at making JWT authentication "work."

Learn:

password hashing
token expiration
refresh token security
secret management
HTTPS
authorization policies
revocation strategies
CORS
CSRF where applicable
secure cookie handling
rate limiting

Security cannot be added at the end like a UI theme.

18. Learn Error Handling Properly

Do not wrap every controller method in this:

try
{
}
catch (Exception ex)
{
    return BadRequest(ex.Message);
}

That quickly becomes unmaintainable and may expose information that clients should never receive.

Prefer centralized exception handling.

Your application might define exceptions such as:

public class ProductNotFoundException : Exception
{
    public ProductNotFoundException(int id)
        : base($"Product {id} was not found.")
    {
    }
}

Then a centralized handler translates exceptions into appropriate HTTP responses.

You should eventually understand Problem Details and consistent API error structures.

For example:

{
  "type": "https://example.com/problems/product-not-found",
  "title": "Product not found",
  "status": 404,
  "detail": "Product 42 does not exist.",
  "traceId": "..."
}

Consistency makes APIs much easier for frontend developers and API consumers to integrate.

19. Learn Logging and Observability

This:

Console.WriteLine("Something happened");

is not production observability.

Use structured logging:

logger.LogInformation(
    "Order {OrderId} created for customer {CustomerId}",
    order.Id,
    order.CustomerId);

Not:

logger.LogInformation(
    $"Order {order.Id} created for customer {order.CustomerId}");

Structured logging allows logging systems to preserve values as searchable fields.

Eventually learn the three major observability signals:

Logs
Metrics
Traces

Also learn:

Correlation IDs
OpenTelemetry
Health checks
Distributed tracing
Alerting

When a production request travels through:

API
↓
Payment Service
↓
Message Broker
↓
Worker
↓
Email Service

you need a way to understand what happened across those boundaries.

20. Learn Testing

Do not wait until you become "advanced" before learning tests.

Start with unit tests.

For example:

public class DiscountService
{
    public decimal Calculate(decimal amount, bool premium)
    {
        if (!premium)
            return amount;

        return amount * 0.9m;
    }
}

Test:

[Fact]
public void Calculate_ShouldApplyDiscount_ForPremiumCustomer()
{
    var service = new DiscountService();

    var result = service.Calculate(100m, true);

    Assert.Equal(90m, result);
}

Then learn integration testing.

For backend systems, integration tests are extremely valuable because many bugs occur between components:

API
Database
Authentication
Serialization
Configuration
Infrastructure

Your progression should be:

Unit Tests
↓
Integration Tests
↓
API Tests
↓
End-to-End Tests where appropriate

Do not chase 100% code coverage.

Test important behavior.

21. Learn Application Architecture

Once you can build working APIs, start thinking about architecture.

A small project can begin simply:

Store.Api

As complexity grows, you might separate concerns:

Store.Api
Store.Application
Store.Domain
Store.Infrastructure
Store.Tests

One possible responsibility split:

Domain

Entities
Value objects
Domain rules
Domain events

Application

Use cases
Commands
Queries
Interfaces
DTOs
Validation

Infrastructure

EF Core
External APIs
Email
Storage
Messaging
Caching

API

HTTP endpoints
Authentication
Middleware
Serialization
Configuration

This resembles Clean Architecture, but the important lesson is not the folder names.

The important lesson is dependency direction.

Your core business logic should not be tightly coupled to every infrastructure decision.

22. Do Not Overengineer Your First Projects

You will encounter architectures and patterns such as:

Clean Architecture
Vertical Slice Architecture
CQRS
DDD
Repository Pattern
Unit of Work
Mediator
Event Sourcing
Microservices
Hexagonal Architecture

Learn them.

Do not automatically use all of them.

A CRUD application does not become enterprise software because it contains:

Controller
Service
Repository
UnitOfWork
Command
Handler
Mapper
Specification
DomainService
Factory
Mediator

for every operation.

Every abstraction has a cost.

Start simple.

Introduce complexity when complexity solves a real problem.

23. Understand the Repository Pattern Debate

You will see tutorials creating:

public interface IProductRepository
{
    Task<Product?> GetByIdAsync(int id);
}

then:

public class ProductRepository : IProductRepository
{
    private readonly ApplicationDbContext _dbContext;
}

This is not automatically wrong.

But neither is using DbContext directly.

EF Core's DbContext already provides repository-like and unit-of-work behavior.

A custom repository can still be useful when it provides meaningful abstraction around domain-specific persistence.

It becomes questionable when it merely converts:

dbContext.Products.FindAsync(id);

into:

productRepository.GetByIdAsync(id);

without adding useful semantics.

Learn why a pattern exists before applying it.

24. Learn Vertical Slice Architecture

Traditional layering often organizes code by technical concern:

Controllers/
Services/
Repositories/
Dtos/
Validators/

As projects grow, implementing one feature can require jumping across many directories.

Vertical Slice Architecture organizes around features.

For example:

Features/
    Products/
        Create/
            Endpoint.cs
            Request.cs
            Validator.cs
            Handler.cs

        GetById/
            Endpoint.cs
            Response.cs
            Handler.cs

    Orders/
        Create/
        Cancel/
        Complete/

This can make feature boundaries clearer.

You do not need to adopt it immediately.

But once you have built a traditional layered application, build another project using vertical slices.

Compare them yourself.

That experience teaches architecture better than architecture diagrams on social media.

25. Learn Caching

Once your application is functional, start thinking about performance.

Suppose this query executes thousands of times:

await dbContext.Categories
    .AsNoTracking()
    .ToListAsync();

and categories rarely change.

Caching may help.

Learn:

In-memory cache
Distributed cache
Redis
Cache expiration
Cache invalidation
Cache-aside

But remember:

Caching makes systems faster by making state management harder.

The question is not:

Can this be cached?

It is:

What happens when the underlying data changes?

Cache invalidation deserves explicit design.

26. Learn Background Processing

Not every task should happen inside an HTTP request.

Suppose checkout needs to:

Create order
Charge payment
Generate invoice
Send email
Update analytics
Notify warehouse

Making the client wait for every secondary operation creates unnecessary coupling.

Some tasks can move to background processing.

Learn about:

hosted services
worker services
background queues
scheduled jobs
Hangfire
Quartz.NET
message brokers

Eventually understand architectures like:

POST /orders
     ↓
Create Order
     ↓
Publish OrderCreated
     ↓
 ┌────────────┬──────────────┐
 ▼            ▼              ▼
Email      Analytics     Fulfillment
Worker      Worker          Worker

That introduces another important subject.

27. Learn Messaging

When building more complex distributed systems, learn:

Queues
Topics
Publish/Subscribe
Acknowledgements
Retries
Dead-letter queues
Idempotency
At-least-once delivery
Eventual consistency

Technologies you may encounter include:

RabbitMQ
Azure Service Bus
Amazon SQS
Kafka

Do not begin your first todo application with Kafka.

First understand why asynchronous messaging exists.

Then use it when system requirements justify it.

28. Learn SignalR for Real-Time Applications

Some systems need server-to-client communication:

Chat
Notifications
Live dashboards
Tracking systems
Collaborative apps
Auction systems
Ticket availability

ASP.NET Core SignalR is designed for real-time application scenarios.

Instead of clients constantly polling:

GET /notifications
GET /notifications
GET /notifications
GET /notifications

the server can push updates when relevant.

Build at least one real-time project.

A small notification system is enough.

It teaches concepts that ordinary CRUD applications do not.

29. Learn Docker

A professional backend developer should understand containers.

Create a Dockerfile:

FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS base
WORKDIR /app
EXPOSE 8080

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src

COPY . .

RUN dotnet restore
RUN dotnet publish -c Release -o /app/publish

FROM base AS final
WORKDIR /app

COPY --from=build /app/publish .

ENTRYPOINT ["dotnet", "Store.Api.dll"]

Then:

docker build -t store-api .

Run it:

docker run -p 8080:8080 store-api

Eventually use Docker Compose for multiple dependencies:

ASP.NET Core
PostgreSQL
Redis
RabbitMQ

Understanding containers makes local development, CI/CD, and cloud deployment much easier to reason about.

30. Learn CI/CD

At some point, stop deploying by manually copying files.

Your pipeline should eventually do something like:

Push
↓
Restore
↓
Build
↓
Test
↓
Security Checks
↓
Build Image
↓
Push Image
↓
Deploy

For GitHub Actions:

name: Build

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: "10.0.x"

      - run: dotnet restore

      - run: dotnet build --no-restore

      - run: dotnet test --no-build

You do not need to become a DevOps engineer.

But a backend developer should understand how code travels from:

Git commit

to:

production

31. Learn One Cloud Platform

You do not need AWS, Azure, and Google Cloud simultaneously.

Choose one.

For .NET developers, Azure is a natural option, but .NET itself is cross-platform and can be deployed in many environments. Microsoft explicitly positions .NET as a platform for building cloud services across operating systems.

Whichever platform you choose, learn concepts rather than memorizing product names.

Understand:

Compute
Managed databases
Object storage
Load balancing
DNS
Networking
Secrets
Queues
Monitoring
Serverless
Containers
Autoscaling

Then map those ideas onto a specific cloud.

Cloud knowledge becomes much easier when you understand infrastructure concepts first.

32. Learn Aspire, But at the Right Time

Aspire is increasingly relevant to modern .NET development.

Microsoft describes Aspire as a multi-language toolchain for orchestrating, running, debugging, and deploying distributed applications during development.

Imagine your application contains:

API
Worker
PostgreSQL
Redis
RabbitMQ
Frontend

Running and configuring the entire environment can become painful.

Aspire helps manage distributed application composition and provides tooling around development and observability. Its dashboard can expose information such as resources, configuration, logs, and related telemetry.

But do not learn Aspire before you understand:

ASP.NET Core
Docker
Databases
Configuration
Services
Observability

Otherwise Aspire becomes another layer of magic.

Understand the underlying system first.

Then use orchestration to simplify it.

33. Learn Performance Basics

You do not need to become a runtime engineer.

But you should recognize common performance problems.

Learn about:

N+1 queries
Missing indexes
Over-fetching
Pagination
Connection pooling
Unnecessary allocations
Blocking async code
Repeated network calls
Caching
Serialization cost
Database round trips

Consider:

var orders = await dbContext.Orders
    .Include(x => x.Customer)
    .Include(x => x.Items)
    .ThenInclude(x => x.Product)
    .ToListAsync();

For ten orders, maybe this is fine.

For hundreds of thousands of records, it may be disastrous.

Ask:

How much data are we loading?
How many queries are generated?
Do we need every column?
Can we project directly?
Is pagination required?
Does the database have the right indexes?

Performance engineering often starts with asking good questions, not writing clever algorithms.

34. Learn Security as an Engineering Discipline

Backend security deserves more than one tutorial.

Learn about:

SQL injection
XSS
CSRF
CORS
Authentication
Authorization
Broken access control
Mass assignment
Secrets management
Password storage
Rate limiting
Input validation
Secure headers
Dependency vulnerabilities
Logging sensitive information

One particularly dangerous bug looks innocent:

GET /api/orders/123

The user is authenticated.

But are they authorized to access order 123?

Authentication alone does not answer that question.

Always think in terms of resource ownership and authorization.

35. Learn Git Beyond git push

Know:

git clone
git status
git add
git commit
git push
git pull
git fetch
git branch
git switch
git merge
git rebase
git stash
git log
git diff

Then understand team workflows:

Feature branches
Pull requests
Code reviews
Merge conflicts
Commit history
Release branches
Tags

Git mistakes are normal.

Not understanding what Git is doing is avoidable.

36. AI Changes How You Should Learn .NET

This is the major difference between learning development a few years ago and learning it in 2026.

AI coding assistants can now generate:

entities
controllers
tests
Dockerfiles
migrations
DTOs
documentation
SQL
CI pipelines
refactoring suggestions
debugging hypotheses

That is useful.

But it creates a dangerous learning path.

A beginner can ask:

Create complete ASP.NET Core clean architecture
with JWT authentication, Redis, RabbitMQ,
PostgreSQL, CQRS and Docker.

The AI may produce hundreds or thousands of lines.

The application might even run.

The developer may understand almost none of it.

That is not productivity.

That is technical debt you cannot see yet.

37. Use AI to Accelerate Understanding, Not Replace It

A better workflow is:

Step 1: Solve the problem yourself

Even if the solution is incomplete.

Step 2: Ask AI to review it

For example:

Review this ASP.NET Core endpoint.

Do not rewrite it yet.

Explain:
1. correctness issues
2. security risks
3. performance problems
4. maintainability problems

Step 3: Compare approaches

Ask:

Show me three ways to structure this,
from simplest to most scalable.

Explain the trade-offs.

Step 4: Make the final decision yourself

You should be able to explain every important architectural decision.

AI should increase your engineering leverage.

It should not remove you from engineering.

38. Learn to Read Documentation

This skill becomes more valuable as AI-generated tutorials increase.

Microsoft maintains extensive documentation for .NET, C#, and ASP.NET Core, including tutorials, conceptual documentation, API references, samples, and language references.

Build the habit:

Problem
↓
Official documentation
↓
Understand concept
↓
Implement
↓
Experiment
↓
Use AI if needed

Not:

Problem
↓
Paste into AI
↓
Paste answer into project
↓
Hope

The second workflow feels faster until something breaks in production.

39. Build Projects in Increasing Difficulty

Tutorial consumption will not make you job-ready.

Projects will.

But project selection matters.

Do not build ten todo apps.

Build progressively harder systems.

Project 1: Task Management API

Features:

Users
Authentication
Projects
Tasks
CRUD
Validation
Pagination
Filtering
SQL
EF Core
Swagger/OpenAPI

You learn:

ASP.NET Core
HTTP
EF Core
JWT
REST

Project 2: E-Commerce Backend

Features:

Products
Categories
Inventory
Customers
Cart
Orders
Payments
Coupons
Admin
Image storage
Search

Add:

Redis
Background jobs
Email
Logging
Docker
Integration tests

You start learning business logic instead of CRUD alone.

Project 3: Real-Time System

Build:

Chat
Live notifications
Delivery tracking
Ticket reservation
Auction platform

Use:

SignalR
Redis
Background services
Concurrency control

Now you encounter distributed-state problems.

Project 4: Distributed Application

Build:

API Gateway
Identity
Order Service
Payment Service
Notification Worker
PostgreSQL
Redis
Message Broker
Observability

Use Aspire or another orchestration approach once the underlying concepts make sense. Aspire is specifically designed to improve the local development experience around distributed applications.

Now you are learning systems engineering rather than framework syntax.

40. Do Not Build Microservices Too Early

Microservices appear frequently in enterprise .NET discussions.

That does not mean your portfolio needs fourteen services.

Start with a modular monolith.

For example:

Application
│
├── Identity
├── Catalog
├── Orders
├── Payments
├── Inventory
└── Notifications

Clear modules inside one deployable application can teach most of the important boundaries without introducing:

Network failures
Distributed transactions
Service discovery
Message delivery
Deployment complexity
Distributed tracing
Cross-service versioning

When you understand the limitations of a modular monolith, microservices will make much more sense.

41. A Practical 6-Month .NET Roadmap

If I were starting today, this is approximately how I would structure six months.

Month 1: C# Fundamentals

Learn:

Syntax
Methods
Classes
Interfaces
Collections
Generics
LINQ
Exceptions
Async/await
Nullable reference types

Build:

Console inventory system

Do not use ASP.NET Core yet.

Month 2: ASP.NET Core + HTTP

Learn:

HTTP
REST
Controllers
Minimal APIs
Routing
Dependency injection
Middleware
Configuration
Logging
OpenAPI

Build:

Task Management API

Month 3: Databases

Learn:

SQL
PostgreSQL or SQL Server
EF Core
Relationships
Migrations
Indexes
Transactions
Pagination
Query optimization

Build:

Inventory Management API

Month 4: Production Backend Concepts

Learn:

Authentication
Authorization
Validation
Error handling
Testing
Caching
Background jobs
Email
File storage

Build:

E-Commerce Backend

Month 5: Infrastructure

Learn:

Docker
Docker Compose
CI/CD
Cloud deployment
Health checks
Logging
Metrics
OpenTelemetry fundamentals

Deploy your application publicly.

Your project should no longer exist only on localhost.

Month 6: Architecture and Distributed Systems

Learn:

Clean Architecture
Vertical Slices
DDD fundamentals
Messaging
SignalR
Distributed caching
Aspire
System design basics

Build one serious portfolio application.

Document the architecture.

Write tests.

Deploy it.

Monitor it.

Break it.

Fix it.

That last part matters.

42. What Should Your GitHub Portfolio Contain?

I would rather see three serious projects than thirty tutorial repositories.

A strong backend project should have:

README
Architecture explanation
Database diagram
API documentation
Docker setup
Tests
CI pipeline
Environment configuration guide
Example requests
Deployment
Screenshots where relevant

Your README should answer:

What does this application do?

Why did you structure it this way?

How do I run it?

What technologies does it use?

What trade-offs did you make?

Architecture explanations are especially valuable.

They prove that you made decisions instead of simply generating code.

43. What a Junior .NET Developer Should Actually Know

You do not need to know everything in this article before applying for jobs.

A solid junior should be comfortable with:

C#
OOP
Collections
LINQ
Async/await

ASP.NET Core
REST APIs
Controllers
Dependency injection
Middleware

SQL
EF Core
Relationships
Migrations

Authentication basics
Git
Testing basics
Docker basics

And most importantly:

You should be able to build an application without following a step-by-step tutorial.

You may use:

documentation
Stack Overflow
AI
GitHub
blogs

Professional developers use references constantly.

The skill is being able to reason about the information you find.

44. What a Mid-Level Developer Needs Beyond That

Moving from junior to mid-level is less about learning another framework and more about judgment.

You should begin understanding:

Why this query is slow

Why this endpoint is insecure

Why this service boundary is wrong

Why this abstraction adds unnecessary complexity

Why this code is difficult to test

Why a background job is better here

Why this operation must be transactional

Why caching may introduce stale data

Why this API contract will become difficult to evolve

Why deployment failed

Why production behaves differently from localhost

That is engineering maturity.

Framework knowledge is only part of it.

45. Common Mistakes When Learning .NET

Mistake 1: Learning only C

C# is the language.

Backend development requires much more.

Learn HTTP, databases, infrastructure, and architecture.

Mistake 2: Learning only ASP.NET Core

Framework knowledge without general software engineering knowledge creates fragile developers.

Learn the underlying concepts.

Mistake 3: Copying Clean Architecture templates

If you cannot explain why each project exists, you probably do not need the architecture yet.

Mistake 4: Avoiding SQL because EF Core exists

Eventually your ORM will generate a slow query.

You need to know why.

Mistake 5: Building only CRUD projects

CRUD is necessary.

It is not enough.

Build systems containing:

Payments
Queues
Caching
Authorization
Concurrency
Real-time communication
Background processing
External integrations

Mistake 6: Starting with microservices

Microservices multiply operational complexity.

Build a good monolith first.

Mistake 7: Depending completely on AI

If AI writes something you cannot debug, the code is effectively owned by nobody.

Mistake 8: Never deploying

Localhost hides problems.

Production teaches:

DNS
TLS
Environment variables
Secrets
Networking
Containers
Database connectivity
Logging
Permissions
Reverse proxies
Deployment failures

Deploy things.

46. The Stack I Would Learn in 2026

If I had to choose one focused backend stack:

Language:
C# 14

Runtime:
.NET 10

Web:
ASP.NET Core 10

Database:
PostgreSQL

ORM:
Entity Framework Core

Cache:
Redis

Real-Time:
SignalR

Messaging:
RabbitMQ or Azure Service Bus

Testing:
xUnit

Containers:
Docker

CI/CD:
GitHub Actions

Cloud:
Azure or AWS

Observability:
OpenTelemetry

Distributed Development:
Aspire

Version Control:
Git + GitHub

The exact technologies are less important than understanding the problems they solve.

For example, once you understand messaging properly, moving from RabbitMQ to another broker becomes much easier.

47. What About Blazor?

ASP.NET Core also includes Blazor for building web UI with .NET, and Microsoft's current ASP.NET Core getting-started material includes Blazor as part of the platform.

Should a backend developer learn it?

Eventually, maybe.

But I would prioritize:

C#
ASP.NET Core APIs
SQL
EF Core
Authentication
Testing
Docker
Cloud

first.

Frontend knowledge is valuable.

Backend depth should come before collecting frameworks.

If you want full-stack .NET development, then Blazor becomes much more relevant.

48. What About MVC?

ASP.NET Core MVC remains part of the modern ASP.NET Core stack and provides the Model-View-Controller pattern for building web apps and APIs.

If your work involves server-rendered applications, existing enterprise applications, or conventional MVC systems, learn it.

But for an API-focused roadmap, you can begin with Web APIs and return to full MVC views later.

49. Learn System Design Gradually

You do not need to memorize how Netflix works.

Start with smaller questions.

Suppose you need to build an URL shortener.

Think:

How are IDs generated?

How are URLs stored?

How does redirection work?

Should reads be cached?

How do we count clicks?

What happens if the database is unavailable?

How would we scale reads?

How do we prevent abuse?

Then move into more complicated systems:

Notification service
Chat system
Payment platform
Ticket reservation
File storage
E-commerce
Real-time tracking

System design becomes useful when connected to actual engineering problems.

50. Learn to Debug Without Immediately Asking AI

When something fails:

500 Internal Server Error

do not immediately paste the entire project into an AI assistant.

Ask:

What changed?

What exception occurred?

Where did it occur?

Can I reproduce it?

What does the stack trace say?

What values entered this code path?

What does the generated SQL look like?

Did configuration change?

Is the problem environment-specific?

Use:

Breakpoints
Debugger
Logs
Stack traces
Database logs
Network inspection
Git diff

Then use AI to accelerate investigation.

A developer who can debug will survive technology changes.

A developer who can only generate code will struggle whenever generated code stops working.

51. The Real Goal Is Not Becoming a ".NET Developer"

Technology stacks change.

Today the current path includes .NET 10, C# 14, ASP.NET Core 10, and increasingly sophisticated distributed-development tooling.

Those versions will eventually change.

The durable skills are:

Programming
Debugging
Data modeling
API design
Testing
Security
Architecture
Distributed systems
Performance
Infrastructure
Communication
Problem solving

.NET is the ecosystem through which you practice those skills.

That distinction matters.

If you only learn framework APIs, every major version feels threatening.

If you understand software engineering, new framework versions mostly become new tools.

Final Roadmap

Here is the complete path in one view:

1. C# fundamentals
        ↓
2. OOP + collections + LINQ
        ↓
3. Async programming
        ↓
4. .NET fundamentals
        ↓
5. HTTP + REST
        ↓
6. ASP.NET Core
        ↓
7. Dependency injection + middleware
        ↓
8. SQL
        ↓
9. Entity Framework Core
        ↓
10. Authentication + authorization
        ↓
11. Validation + error handling
        ↓
12. Testing
        ↓
13. Logging + observability
        ↓
14. Caching + background processing
        ↓
15. SignalR + messaging
        ↓
16. Application architecture
        ↓
17. Docker
        ↓
18. CI/CD
        ↓
19. Cloud
        ↓
20. Aspire + distributed systems
        ↓
21. Performance + security
        ↓
22. Real production projects

You do not need to complete this roadmap before calling yourself a .NET developer.

Start much earlier.

Build something after every major stage.

Do not spend six months preparing to build your first application.

Build badly.

Discover why it is bad.

Refactor it.

Deploy it.

Break it.

Debug it.

Build the next version better.

In 2026, AI can generate more code in minutes than a developer could manually write in days.

That makes understanding code more valuable, not less.

The developers who will benefit most from AI are not those who know the most prompts.

They are the developers who understand systems well enough to decide:

what should be built
how it should be structured
whether generated code is correct
where it will fail
how it should be secured
how it should scale
and whether the complexity is justified

Learn C#.

Learn .NET.

But above all, learn software engineering.

That is how you become a .NET developer who remains useful after the next framework release.

How to Survive as a Software Engineer in the Age of AI

Moniruzzaman Saikat — Fri, 07 Aug 2026 06:43:12 +0000

Software engineering is changing faster than at any point in recent memory.

A few years ago, AI-assisted development mostly meant autocomplete. Today, developers can ask an AI agent to inspect a repository, implement a feature, generate tests, debug an error, refactor several files, explain unfamiliar code, write database migrations, create API documentation, and review a pull request.

The obvious question is:

If AI can write increasingly large amounts of software, what happens to software engineers?

I think the wrong response is trying to compete with AI at typing code.

The better response is becoming the engineer who knows what should be built, how it should be designed, whether the generated implementation is correct, and how the entire system behaves in production.

AI is making code cheaper.

Engineering is not becoming cheaper.

In many ways, engineering judgment is becoming more valuable.

This article is about how software engineers can adapt to that change and remain valuable even as AI becomes dramatically better at writing code.

The uncomfortable truth: code generation is becoming a commodity

For decades, being able to translate requirements into working code was one of the most valuable skills in software development.

That is still valuable.

But the economics are changing.

Suppose a company needs:

a CRUD dashboard
REST APIs
authentication
database migrations
validation
unit tests
a React interface
Docker configuration
CI/CD
documentation

Five years ago, producing all of this required a significant amount of manual development.

Today, an experienced developer using modern AI tools can generate a large portion of it much faster.

The developer is still necessary, but the bottleneck has moved.

The difficult part increasingly becomes:

understanding the actual requirement
deciding the architecture
defining boundaries
identifying edge cases
reviewing generated code
protecting security
handling failures
designing data correctly
operating the system
deciding what should not be built

This distinction matters.

If your value proposition is:

"I can write controllers faster than another developer."

AI is becoming serious competition.

If your value proposition is:

"I can take an unclear business problem, design a maintainable system, use AI to accelerate implementation, verify the result, deploy it safely, and operate it at scale."

You are much harder to replace.

AI will not remove software engineering

It will remove parts of software engineering.

That has happened repeatedly throughout the history of our industry.

Developers once manually managed memory for almost everything.

Then garbage collection became common.

Developers once manually configured physical servers.

Then virtualization appeared.

Then cloud computing.

Then infrastructure as code.

Developers once manually created almost every UI component.

Then component libraries and frameworks became widespread.

Developers once manually searched documentation every time they forgot an API.

Then search engines, Stack Overflow, IDE intelligence, and eventually AI assistants changed that workflow.

Each abstraction removed work.

It did not remove software development.

Instead, developers started building more complicated systems.

AI is another abstraction layer, although potentially a much larger one.

The important question is therefore not:

"Will AI write code?"

It obviously will.

The important question is:

"What skills become valuable when producing code itself becomes significantly easier?"

That is where engineers should focus.

1. Stop identifying yourself by how much code you write

A common mistake developers make is measuring productivity through code production.

Lines of code.

Number of commits.

Number of endpoints.

Number of features implemented.

These were never particularly good measurements.

With AI, they become even less meaningful.

Consider two developers.

Developer A writes 3,000 lines of code implementing a complicated permission system.

Developer B realizes the requirements can be solved using the application's existing authorization model and implements the same functionality in 300 lines.

Who produced more value?

Probably Developer B.

Now add AI.

An AI agent might generate those 3,000 lines in minutes.

That does not automatically make the implementation good.

More code means:

more paths to test
more places for bugs
more maintenance
more cognitive load
more security surface
more dependencies
more opportunities for inconsistent behavior

The valuable engineer is increasingly the person who knows which code does not need to exist.

2. Become excellent at problem decomposition

One of the most useful skills in AI-assisted development is breaking large problems into well-defined smaller problems.

Consider this requirement:

Build a notification system.

That sounds simple.

But an experienced engineer immediately starts asking questions.

What channels exist?

email
SMS
push notifications
in-app notifications
webhooks

Are notifications synchronous or asynchronous?

Can users configure preferences?

What happens when delivery fails?

Should retries occur?

How many retries?

Do we need idempotency?

Do notifications have priority levels?

How do we prevent duplicate delivery?

Should messages be localized?

Are there rate limits?

How will providers be switched?

Do we need delivery analytics?

How long should notification history be retained?

Do users need unread counters?

What happens when one provider goes down?

The difference between junior and senior engineering often exists inside these questions.

AI can generate a notification service.

But if your request is poorly structured, you may receive an implementation that looks impressive while failing under real production conditions.

Good engineers turn vague requirements into clear constraints.

For example:

Notification Service

Channels:
- Email
- SMS
- In-app

Delivery:
- Queue based
- At least once delivery

Requirements:
- Idempotency key for each message
- Exponential retry
- Maximum 5 attempts
- Dead letter queue after failure
- User-level channel preferences
- Provider abstraction
- Delivery logs
- Per-provider rate limiting

Volume:
- 1 million notifications/day

Latency:
- 95% of queued messages processed within 30 seconds

Now AI has something useful to work with.

Your ability to structure problems determines the quality of your AI-assisted output.

3. Learn system design

If there is one area I would recommend developers invest heavily in, it is system design.

AI can generate individual components quickly.

But real systems involve interactions between components.

Consider building something like Uber.

The UI might be relatively straightforward.

The difficult engineering questions are elsewhere.

How do you track drivers?

How frequently should location be updated?

Where should location data live?

How do you find nearby drivers efficiently?

What happens when two drivers accept the same request?

How do you prevent duplicate rides?

How do you process payments?

How do you handle unreliable mobile networks?

How do you synchronize ride state?

How do you scale WebSocket connections?

How do you distribute requests geographically?

How do you recover from partial failures?

How do you handle event ordering?

How do you detect fraudulent behavior?

AI can help implement each subsystem.

But somebody still needs to understand how they fit together.

That requires knowledge of:

distributed systems
databases
networking
queues
caching
concurrency
consistency
availability
fault tolerance
observability
security

These concepts become more important as AI allows engineers to build larger systems faster.

4. Become very good at reading code

There is an interesting shift happening.

Historically, developers spent significant amounts of time writing code.

AI-assisted developers increasingly spend more time reviewing code.

Imagine an AI agent produces this pull request:

+2,847 lines
-431 lines
23 files changed

The AI claims:

Implemented payment retry logic with idempotency protection.

Your job is not finished.

It has barely started.

You need to understand:

Does the implementation match the requirements?
Can duplicate payments occur?
Are transactions handled correctly?
What happens when the payment provider times out?
Is the retry logic safe?
Is there a race condition?
Are logs leaking payment information?
Are errors observable?
Are tests meaningful?
Did the agent modify unrelated code?

The ability to understand unfamiliar code quickly becomes extremely valuable.

This means developers should practice:

reading large codebases
tracing execution paths
understanding call graphs
analyzing database queries
identifying side effects
recognizing architectural boundaries
spotting suspicious abstractions

You do not want to become someone who can only produce software through prompts.

If an AI writes something you cannot understand, you do not really control the software.

5. Master debugging

AI is excellent when the problem is clearly described.

Production bugs often are not.

Imagine customers report:

Checkout occasionally freezes.

That is the entire bug report.

The logs show nothing obvious.

It only happens approximately 2 percent of the time.

Now you have an engineering investigation.

You might inspect:

Browser
   ↓
Load Balancer
   ↓
Application API
   ↓
Payment Service
   ↓
Database
   ↓
Queue
   ↓
External Payment Gateway

The problem might be:

connection pool exhaustion
database locks
request timeout configuration
payment gateway latency
duplicate transaction locks
Redis failure
queue congestion
race conditions
frontend retry behavior
DNS resolution
network packet loss

AI can help investigate each possibility.

But someone still needs to form hypotheses and gather evidence.

Strong debugging requires a mental model of the system.

The typical process looks something like this:

Symptom
  ↓
Collect evidence
  ↓
Form hypothesis
  ↓
Design experiment
  ↓
Validate
  ↓
Identify root cause
  ↓
Implement fix
  ↓
Verify
  ↓
Prevent recurrence

Developers who can debug complicated systems will continue to be extremely valuable.

6. Learn how databases actually work

AI can generate SQL.

That does not mean the SQL is good.

For example:

SELECT *
FROM orders
WHERE user_id = 123
ORDER BY created_at DESC;

Looks fine.

Now imagine the orders table contains 500 million rows.

Suddenly questions appear.

Do we have an index?

Should it be:

INDEX(user_id)

or:

INDEX(user_id, created_at)

What does the query plan show?

Should old orders be archived?

Should the table be partitioned?

Would a read replica help?

What is the write volume?

What isolation level is being used?

Could this query contribute to lock contention?

AI can suggest answers.

But database performance depends heavily on actual workload.

Engineers should understand:

indexes
transactions
isolation levels
query plans
locking
normalization
denormalization
replication
partitioning
connection pools
caching

Database mistakes often remain invisible during development and become expensive only after scale arrives.

7. Understand distributed systems

Once applications become large enough, distributed systems problems appear everywhere.

You may have:

Client
  ↓
API Gateway
  ↓
Authentication Service
  ↓
Order Service
  ↓
Payment Service
  ↓
Inventory Service
  ↓
Message Queue
  ↓
Notification Service

Now everything can fail independently.

The payment may succeed while your API request times out.

The message broker may deliver the same event twice.

Events may arrive in the wrong order.

A database may become temporarily unavailable.

Two services may disagree about state.

Understanding concepts such as these becomes important:

Idempotency

The same request should be safe to execute multiple times where required.

Eventual consistency

Different parts of the system may temporarily contain different states.

Retry strategies

Retries must avoid overwhelming an already failing dependency.

Circuit breakers

Stop repeatedly calling unhealthy services.

Dead-letter queues

Preserve messages that repeatedly fail processing.

Distributed tracing

Follow a request across multiple services.

Saga patterns

Coordinate multi-step business transactions without a global database transaction.

AI can implement these patterns.

But choosing the wrong pattern can make a system significantly more complicated.

Architecture is about knowing when complexity is justified.

8. Learn networking fundamentals

Many developers know frameworks extremely well but have only a vague understanding of what happens between:

fetch("/api/orders")

and the server receiving the request.

That knowledge becomes extremely useful during production incidents.

Understand:

DNS
TCP
HTTP
TLS
proxies
load balancers
CDN behavior
WebSockets
connection pooling
timeouts
retries
ports
firewalls

When a customer says:

The website works on mobile data but not Wi-Fi.

Framework knowledge will probably not solve the problem.

Networking knowledge might.

9. Security knowledge becomes more important

AI makes software easier to produce.

Unfortunately, it also makes insecure software easier to produce.

Suppose an AI generates:

$user = User::find($request->user_id);

$user->update([
    'role' => $request->role
]);

The code works.

But should the current user be able to modify that user?

Should they be able to assign the admin role?

Where is authorization?

Where is validation?

Could mass assignment create additional problems?

AI often optimizes toward "make the feature work."

Production engineers must think:

How can this feature fail or be abused?

Developers should understand:

authentication
authorization
SQL injection
XSS
CSRF
SSRF
insecure direct object references
secret management
credential rotation
API security
encryption
rate limiting
dependency vulnerabilities

AI increases development speed.

Security review must keep pace.

10. Treat AI output like code from a very fast junior developer

This mental model is useful.

Imagine a developer who:

types extremely quickly
knows thousands of libraries
never becomes tired
can read enormous amounts of code
produces solutions immediately

But this developer can also:

misunderstand requirements
invent APIs
introduce security vulnerabilities
over-engineer solutions
miss subtle race conditions
confidently explain incorrect assumptions

Would you deploy everything they wrote without review?

Probably not.

That is roughly how AI-generated code should be treated.

Use it aggressively.

Trust it selectively.

Verify important behavior.

11. Learn to give AI context, not just prompts

Developers often focus too much on "prompt engineering."

For serious software development, context engineering is more important.

Compare these requests.

Bad:

Create authentication.

Better:

Implement authentication using Laravel Sanctum.

Requirements:
- Existing User model must remain unchanged
- Authentication is API-only
- Use Form Requests for validation
- Controllers should contain no business logic
- Authentication logic belongs in AuthService
- Responses must use existing ApiResponse helper
- Add feature tests
- Do not add new dependencies

Even better is providing AI access to:

architecture documentation
coding standards
database schema
existing examples
test conventions
domain terminology
repository structure

The quality of AI-generated code depends heavily on the quality of context.

12. Build architectural guardrails

This becomes particularly important when AI agents produce larger amounts of code.

Suppose your architecture requires:

Controller
   ↓
Service
   ↓
Repository
   ↓
Database

Without enforcement, AI might produce:

Controller
   ↓
Database

or:

Controller
   ↓
RandomHelper
   ↓
Repository

or place business logic directly inside routes.

Documentation helps.

Automated enforcement is better.

Use tools such as:

static analysis
linters
dependency rules
architectural tests
type systems
automated tests
formatting rules
CI checks

For example, architecture rules can enforce:

Controllers cannot directly access repositories.

Domain modules cannot import infrastructure modules.

Payment code cannot import UI modules.

When AI generates code, deterministic rules can reject invalid implementations automatically.

This creates an important pattern:

Human defines architecture
        ↓
AI generates implementation
        ↓
Automated rules validate structure
        ↓
Tests validate behavior
        ↓
Human reviews important decisions

That is significantly more scalable than manually inspecting everything.

13. Testing becomes more valuable, not less

AI can generate code faster than humans can manually verify it.

That means automated verification becomes critical.

Suppose an agent generates ten features in an afternoon.

Without tests, your verification burden becomes enormous.

With a strong test suite, you can quickly detect regressions.

Your development workflow might become:

Requirement
    ↓
AI implementation
    ↓
Static analysis
    ↓
Unit tests
    ↓
Integration tests
    ↓
Architecture tests
    ↓
Security checks
    ↓
Human review

Tests become part of the control system around AI.

A good engineer does not only ask:

Can AI write this feature?

They ask:

How will I know the feature is correct?

14. Learn observability

Many software bugs cannot be reproduced locally.

You need visibility into production.

That means understanding:

structured logs
metrics
tracing
dashboards
alerts
error tracking

Consider a request traveling through several systems.

POST /checkout
      ↓
Order API
      ↓
Inventory Service
      ↓
Payment Service
      ↓
Payment Gateway

Without tracing, you may only know:

Checkout failed.

With distributed tracing:

POST /checkout               4.8s
 ├── inventory.reserve       80ms
 ├── order.create            35ms
 └── payment.charge          4.6s
      └── external.gateway   4.5s

Now the problem becomes much easier to understand.

AI can help interpret telemetry.

But telemetry must exist first.

15. Learn cloud and infrastructure

You do not need to become a full-time DevOps engineer.

You should understand how software actually runs.

Learn the basics of:

Linux
containers
Docker
reverse proxies
CI/CD
cloud computing
load balancing
autoscaling
DNS
storage
secrets
monitoring

An engineer who can write an application but cannot understand its production environment has a major blind spot.

AI makes deploying software easier.

That means more developers will deploy software.

Production knowledge therefore becomes more valuable, not less.

16. Understand cost

A system can be technically correct and financially terrible.

Imagine an AI feature that sends every request to a powerful LLM.

Suppose:

100,000 users
× 20 requests/day
= 2,000,000 AI requests/day

A tiny architectural decision can suddenly become a major monthly expense.

The same applies to:

database queries
object storage
bandwidth
logging
background jobs
serverless execution
API providers

Good engineers think about economics.

Questions include:

Can this operation be cached?
Can requests be batched?
Does this data need permanent storage?
Should this workload run asynchronously?
Do we need this expensive model?
Could a deterministic algorithm solve this?
Can we reduce token consumption?

Engineering is not only about making systems work.

It is about making them sustainable.

17. Develop product thinking

This may be one of the biggest career advantages in the AI era.

Developers traditionally receive requirements:

Build feature X.

Strong product engineers ask:

Why?

Suppose somebody requests:

Add real-time notifications using WebSockets.

Before implementation, ask:

What problem are we solving?

Maybe users simply need to know when a report is finished.

A full WebSocket infrastructure might be unnecessary.

Possible alternatives:

Polling
Server-Sent Events
Push notifications
Email
Background refresh
WebSockets

The correct engineering solution depends on the product requirement.

AI can quickly implement the wrong solution.

Engineers must determine the right one.

18. Communication becomes a technical skill

The stereotype of the brilliant developer who cannot communicate becomes increasingly difficult to sustain.

Modern engineering involves constant communication with:

product managers
designers
customers
DevOps engineers
security teams
executives
other developers
AI agents

Engineers need to explain:

trade-offs
risks
architecture
timelines
technical limitations
failure scenarios
alternative approaches

Consider the difference between:

We need to refactor the backend.

and:

Checkout failures are increasing because payment processing and order creation currently share one synchronous transaction. Separating payment processing into an asynchronous workflow would reduce request failures, but it requires approximately two weeks of engineering and introduces eventual consistency.

The second explanation allows the business to make a decision.

That is engineering communication.

19. Specialize, but understand the full system

There is a common debate:

Should developers become specialists or generalists?

The best answer is usually both.

You want depth in one or two areas.

For example:

Backend Engineering
        ↓
Laravel / .NET / Node.js
        ↓
Databases
        ↓
Distributed Systems

But you should understand adjacent systems:

Frontend
Cloud
Networking
Security
DevOps
Product
AI

You do not need expert-level knowledge everywhere.

You need enough knowledge to understand how your decisions affect the overall system.

This is sometimes called a T-shaped skill profile.

AI makes this particularly powerful because it can help fill temporary knowledge gaps while your deeper expertise provides judgment.

20. Do not become framework-dependent

Framework knowledge is useful.

Framework identity is dangerous.

If your professional identity is:

I am a Laravel developer.

then a major change in Laravel, PHP, or market demand can feel threatening.

A more durable identity is:

I am a backend engineer who currently uses Laravel heavily.

The difference is subtle but important.

Learn concepts underneath frameworks.

Instead of only learning:

Cache::remember(...)

understand:

cache-aside
TTL
invalidation
distributed caching
cache stampedes
consistency trade-offs

Instead of only learning:

DB::transaction(...)

understand:

ACID
locks
isolation
deadlocks
transaction boundaries

Framework APIs change.

Engineering concepts survive much longer.

21. Learn multiple paradigms

You do not need to learn every programming language.

But learning different ecosystems expands how you think.

For example:

Laravel teaches productive web application development.

Go may teach simplicity and concurrency.

Rust forces you to think carefully about memory and ownership.

Java or C# introduces mature enterprise architecture patterns.

JavaScript exposes asynchronous programming deeply.

SQL teaches declarative thinking.

Functional languages introduce immutability and composition.

AI makes exploring new languages dramatically easier.

You can ask it:

I know Laravel.

Explain dependency injection in ASP.NET Core by comparing it with Laravel's service container.

Or:

Explain Go channels using concepts familiar to a Node.js developer.

Use AI as a learning accelerator.

22. Build things

Reading about AI will not prepare you for AI-assisted engineering.

Using it will.

Take a real project.

Build something with:

authentication
API
database
caching
queues
WebSockets
background workers
monitoring
CI/CD
production deployment

Use AI throughout the process.

But pay attention to where it succeeds and fails.

You will quickly discover something.

AI is extremely good when:

requirements are precise
patterns already exist
tasks are local
tests define expected behavior
architecture is clear

AI becomes less reliable when:

requirements are ambiguous
multiple services interact
business rules are undocumented
bugs are non-deterministic
infrastructure is involved
historical architectural decisions matter

That experience is difficult to learn from tutorials.

23. Build reusable engineering systems

One major productivity advantage is creating reusable infrastructure.

Instead of asking AI to design your architecture from scratch for every project, build templates.

For example:

my-saas-template/
├── auth/
├── billing/
├── notifications/
├── queue/
├── monitoring/
├── logging/
├── docker/
├── ci/
└── tests/

Include:

coding standards
architecture guidelines
authentication
authorization
error handling
API conventions
test infrastructure
logging
CI/CD

Then AI operates inside a known environment.

This produces far more predictable results.

24. Learn to manage AI agents

There is an emerging engineering skill that did not exist in the same form a few years ago.

Managing coding agents.

Instead of:

Developer → Code

the workflow becomes:

Developer
   ↓
Task definition
   ↓
AI agent
   ↓
Implementation
   ↓
Automated verification
   ↓
Developer review

Eventually one engineer may coordinate multiple agents.

For example:

Engineer

├── Agent A: Backend API
├── Agent B: Frontend
├── Agent C: Tests
├── Agent D: Documentation
└── Agent E: Code review

The engineer becomes partly an orchestrator.

But orchestration requires architecture.

Without clear boundaries, multiple agents can produce conflicting implementations.

The human must define:

interfaces
ownership
constraints
acceptance criteria
architectural rules

This is much closer to technical leadership than traditional solo coding.

25. Use AI to increase your learning speed

One of the biggest opportunities of AI is not code generation.

It is education.

Previously, learning distributed systems might involve:

books
courses
documentation
blog posts
experimentation

Those are still valuable.

But now you can have interactive explanations.

For example:

Explain database isolation levels using an e-commerce checkout example.

Then:

Show me how a race condition can happen under READ COMMITTED.

Then:

Write a PostgreSQL example that reproduces the race condition.

Then:

Show three ways to fix it and explain the trade-offs.

Then:

Quiz me on the concept.

This creates an incredibly powerful learning environment.

Developers who use AI only for generating CRUD code are missing a much larger opportunity.

26. Build your own judgment

There is one dangerous side effect of AI-assisted development.

You can appear more capable than you actually are.

A developer might generate:

Kubernetes manifests
distributed queues
event-driven systems
complex SQL
encryption code
OAuth flows

without truly understanding any of them.

Everything works until it does not.

Then the developer has no mental model for debugging the system.

Avoid this trap.

Whenever AI generates something important, ask:

Why does this work?

What assumptions does it make?

What can fail?

What alternatives exist?

What trade-offs were made?

How would this behave under load?

You do not need to manually write every line.

You should understand the important decisions.

27. Learn when not to use AI

AI is not automatically the best tool for every problem.

Sometimes writing five lines yourself is faster than describing them.

Sometimes deterministic tooling is safer.

Sometimes documentation is more authoritative.

Sometimes a compiler error tells you exactly what is wrong.

Sometimes production telemetry matters more than AI speculation.

Sometimes a simple shell command gives the answer immediately.

Good engineers choose tools based on the problem.

Not because the tool is fashionable.

28. Your GitHub activity may change

Traditional developer portfolios often emphasize commits.

In an AI-heavy development environment, commits may become less meaningful.

Imagine one engineer producing the equivalent implementation output of several developers because AI agents handle much of the mechanical work.

What becomes interesting instead?

Projects that demonstrate:

architectural quality
production readiness
reliability
scale
thoughtful technical decisions
documentation
observability
security
real users

A small production system with thoughtful engineering can demonstrate more ability than hundreds of tutorial repositories.

29. Junior developers face the biggest challenge

Entry-level developers traditionally learned through tasks such as:

Create this CRUD page.
Fix this validation bug.
Add this endpoint.
Write this migration.
Update this component.

AI can already handle many of those tasks.

That creates a difficult question:

How do juniors gain experience if beginner tasks disappear?

The answer is not skipping fundamentals.

It is learning them faster.

Junior developers should spend serious time understanding:

data structures
algorithms
HTTP
SQL
Git
debugging
operating systems
networking
testing
software design

Then use AI to build significantly more projects than previous generations could.

A junior engineer who has built and operated ten serious applications with AI assistance may gain exposure to problems that previously required several years of work.

The opportunity is enormous if AI is used for learning rather than replacing thinking.

30. Senior developers must change too

Experience does not automatically protect someone from disruption.

A senior engineer who refuses AI may eventually compete against engineers of similar experience who use AI effectively.

Imagine two senior developers.

Both understand:

architecture
databases
distributed systems
product engineering

But one also uses AI effectively for:

repository exploration
test generation
implementation
refactoring
documentation
debugging
research

That developer may be significantly faster.

The future is probably not:

AI vs developers

It is:

Developers using AI
vs
Developers not using AI effectively

31. A practical AI-assisted engineering workflow

Here is a workflow I think works well.

Step 1: Understand the problem yourself

Do not immediately ask AI to code.

Write:

Problem
Constraints
Expected behavior
Edge cases
Performance requirements
Security requirements

Step 2: Design the architecture

Define:

Components
Responsibilities
Data model
Interfaces
Dependencies
Failure modes

You can ask AI to critique your design.

Do not automatically ask AI to make every architectural decision.

Step 3: Define acceptance criteria

Example:

Given a user has already paid an invoice,
when the payment webhook is delivered again,
the system must not create another payment.

Acceptance criteria reduce ambiguity.

Step 4: Ask AI to implement a small slice

Prefer:

Implement PaymentWebhookHandler only.

over:

Build the entire billing system.

Smaller changes are easier to review.

Step 5: Run automated verification

Use:

Tests
Static analysis
Type checking
Linting
Security scanning
Architecture checks

Step 6: Review the code

Inspect:

Correctness
Security
Error handling
Performance
Maintainability
Architecture

Step 7: Test failure scenarios

Ask:

What if Redis is unavailable?

What if this request runs twice?

What if the payment provider times out?

What if the database transaction fails?

What if two workers process this simultaneously?

Happy paths are easy.

Production systems fail through unhappy paths.

32. Skills I would learn if I were starting today

If I were preparing for the next several years of software engineering, I would prioritize roughly this stack.

Core programming

Learn at least one language deeply.

Understand:

data structures
algorithms
concurrency
memory basics
error handling
type systems

Backend fundamentals

Understand:

HTTP
REST
authentication
authorization
caching
queues
background jobs
WebSockets

Databases

Learn SQL seriously.

Understand:

indexes
transactions
locking
query plans
replication

Infrastructure

Learn:

Linux
Docker
CI/CD
cloud fundamentals
DNS
load balancing

Software architecture

Study:

modularity
domain boundaries
event-driven architecture
distributed systems
failure handling

Security

Understand common application vulnerabilities and secure engineering practices.

AI-assisted development

Learn how to:

provide repository context
design agent tasks
review generated code
build automated guardrails
use AI for debugging
use AI for learning

Communication

Practice writing:

design documents
technical proposals
incident reports
architecture explanations

That combination creates an engineer who can operate well above the code-generation layer.

33. The new abstraction layer of software engineering

Software development has continuously moved upward.

We went from:

Machine code
    ↓
Assembly
    ↓
High-level languages
    ↓
Frameworks
    ↓
Cloud platforms
    ↓
AI-assisted development

Each layer makes the lower layer easier to manipulate.

But somebody still needs to understand what the system should do.

The developer of the future may spend less time manually implementing every detail.

Instead, they may spend more time:

designing systems
defining constraints
reviewing generated changes
coordinating agents
analyzing production behavior
improving developer infrastructure
making product decisions

That does not sound like the death of software engineering.

It sounds like another evolution of it.

34. Do not try to beat AI at being AI

AI has several advantages you cannot compete with.

It can read faster.

It can generate code faster.

It can search enormous amounts of information.

It does not become tired after writing repetitive tests.

Trying to preserve your career by becoming a faster code typist is probably the wrong strategy.

Focus on things where engineering judgment matters:

What should we build?

Why should we build it?

How should the system behave?

What can go wrong?

What architecture fits the problem?

What trade-offs are acceptable?

How do we know the implementation is correct?

How will we operate it in production?

Those are much harder questions.

35. The strongest engineer may produce less code

This is perhaps the strangest consequence of AI-assisted development.

A highly productive engineer may personally type less code than before.

Instead, they might spend their day:

30 minutes understanding requirements

45 minutes designing architecture

20 minutes defining implementation tasks

AI generates code

40 minutes reviewing changes

30 minutes testing failure scenarios

20 minutes reviewing observability

15 minutes documenting architectural decisions

The final output might represent several days of traditional implementation work.

The engineer still did significant engineering.

Typing simply became a smaller part of it.

What should you do starting now?

Do not panic about AI.

But do not ignore it either.

Use it every day.

Use it to build.

Use it to learn.

Use it to read unfamiliar repositories.

Use it to write tests.

Use it to challenge your architecture.

Use it to investigate bugs.

Use it to automate repetitive work.

At the same time, strengthen the skills AI-generated code still depends on:

architecture
debugging
databases
distributed systems
networking
security
testing
infrastructure
product thinking
communication

Most importantly, keep understanding the systems you build.

Do not become a developer whose entire engineering process is:

Prompt
↓
Copy
↓
Paste
↓
Deploy

Build a process closer to:

Understand
↓
Design
↓
Specify
↓
Generate
↓
Verify
↓
Observe
↓
Improve

That difference matters.

Final Thoughts

AI is going to write a lot of software.

That is no longer a particularly controversial prediction.

But software engineering has never been only about writing code.

The difficult parts have always included understanding incomplete requirements, managing complexity, debugging strange behavior, making architectural trade-offs, protecting users, operating systems reliably, and deciding what should be built.

AI makes implementation faster.

That means engineers can attempt larger things.

And larger systems create more engineering problems, not fewer.

So the goal should not be surviving AI by avoiding it.

The goal should be moving one abstraction level higher.

Become the engineer who can use AI to transform an idea into a reliable system.

Understand the problem.

Design the architecture.

Define the constraints.

Let AI accelerate the mechanical work.

Then verify everything that matters.

The developers who do that will not simply survive the AI era.

They will be able to build more than software engineers from any previous generation.

How to Build Scalable Software Using AI Without Creating an Unmaintainable Mess

Moniruzzaman Saikat — Fri, 07 Aug 2026 05:03:58 +0000

AI has changed the speed at which software can be built.

A developer can describe an API endpoint and receive an implementation in seconds. An AI coding agent can inspect a repository, modify multiple files, generate tests, run commands, debug failures, and prepare a pull request.

This is a significant improvement in development productivity.

It also creates a new problem.

Generating software faster does not mean generating scalable software.

In fact, AI can help you create a poorly designed system faster than ever.

Ask an AI agent to "build a complete SaaS backend" and it may happily generate controllers, models, migrations, services, background jobs, authentication, caching, queues, and dozens of abstractions.

The application may even work.

Then six months later:

changing one feature breaks three others
database queries become increasingly expensive
business logic exists in five different places
background jobs execute twice
APIs become inconsistent
every developer implements things differently
tests become difficult to maintain
AI agents make increasingly dangerous changes because the architecture is unclear

The fundamental lesson is simple:

AI increases implementation capacity. Architecture determines whether that capacity produces a scalable system.

Building scalable software with AI therefore requires a different mindset from simply using AI to write code.

You need to design the environment in which AI writes code.

You need architectural boundaries.

You need rules.

You need automated verification.

You need documentation that machines can understand.

And increasingly, you need to treat your repository as an operating environment for both human developers and software engineering agents.

This article explains how to do that.

What Does "Scalable Software" Actually Mean?

Developers often use scalability to mean:

"The system can handle more traffic."

That is only one form of scalability.

A production system has to scale across several dimensions.

Traffic scalability

Can the system handle:

100 users
1,000 users
100,000 users
1,000,000 users

without collapsing?

This involves:

application servers
database performance
caching
queues
load balancing
storage
connection management
horizontal scaling

Data scalability

What happens when:

orders = 10,000

becomes:

orders = 500,000,000

Queries that looked harmless during development may become serious bottlenecks.

Team scalability

Can twenty developers work on the codebase without constantly breaking each other's changes?

A system can handle millions of requests and still have terrible engineering scalability.

Feature scalability

Can you add new functionality without modifying half the application?

Good architecture minimizes the number of unrelated components affected by a change.

Operational scalability

Can your team understand what is happening when production fails?

Can you answer:

Why is checkout slow?

Which service is failing?

Which request triggered this exception?

How many jobs are stuck?

Which deployment introduced the regression?

AI scalability

There is now another dimension worth considering.

Can multiple AI coding agents safely contribute to the repository?

This is becoming increasingly relevant.

Coding systems such as Codex and GitHub Copilot support repository-level instructions that give agents persistent information about project structure, conventions, testing, and validation. OpenAI recommends AGENTS.md for persistent repository context, while GitHub Copilot supports repository instructions and AGENTS.md files for similar purposes.

That means modern software architecture must increasingly optimize for two types of developers:

Human developers
+
AI engineering agents

Fortunately, the things that make software easier for AI to understand are usually the same things that make it easier for humans to maintain.

AI Should Be an Implementation Engine, Not Your Architect

One of the most dangerous prompts in AI-assisted development is something like:

Build the complete backend architecture for my SaaS.

The problem is not that AI cannot produce architecture.

It can.

The problem is that architecture is a collection of contextual decisions.

Consider a payment system.

Should you use:

monolith?
modular monolith?
microservices?
event-driven architecture?
serverless?

There is no universally correct answer.

The decision depends on:

expected traffic
engineering team size
deployment model
transaction requirements
data consistency requirements
operational capabilities
budget
expected product evolution
failure tolerance
integration requirements

AI does not automatically know these constraints.

If you ask it to decide without supplying them, it will fill the missing context with assumptions.

The code may be technically reasonable while being completely wrong for your product.

A better relationship looks like this:

Human:
defines architecture

AI:
explores options
implements components
writes tests
performs refactoring
finds inconsistencies
reviews code
generates documentation
investigates failures

Think of AI as an extremely fast engineering team working inside boundaries that you define.

Start With Architecture Before Writing Prompts

Suppose we are building a project management SaaS.

A naive architecture might look like:

Frontend
   |
Backend API
   |
Database

This is technically architecture, but it tells an AI agent almost nothing.

Instead, define the important boundaries.

                    ┌──────────────────┐
                    │     Web App      │
                    └────────┬─────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │    API Layer     │
                    └────────┬─────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
              ▼              ▼              ▼
        ┌──────────┐   ┌──────────┐   ┌──────────┐
        │ Projects │   │ Billing  │   │ Accounts │
        └─────┬────┘   └────┬─────┘   └────┬─────┘
              │             │              │
              └─────────────┼──────────────┘
                            │
                            ▼
                    ┌──────────────────┐
                    │     Database     │
                    └──────────────────┘

                     Background Work
                            │
                            ▼
                    ┌──────────────────┐
                    │      Queue       │
                    └──────────────────┘

Now define responsibilities.

API layer

Responsible for:

authentication
request parsing
validation
authorization
response formatting

Not responsible for business rules.

Project module

Responsible for:

projects
tasks
assignments
project permissions
project workflows

Billing module

Responsible for:

subscriptions
invoices
payments
billing providers
usage calculations

Account module

Responsible for:

organizations
users
memberships
roles

This creates boundaries an AI agent can follow.

Start With a Modular Monolith More Often Than You Think

AI makes microservices unusually tempting.

You can ask:

Create an authentication microservice.

Then:

Create a billing microservice.

Then:

Create an order service.

Soon you have twelve services.

Unfortunately, you also have:

twelve deployments
twelve logs
twelve CI pipelines
distributed tracing
network failures
duplicated authentication logic
service discovery
asynchronous consistency
versioned contracts
complicated local development

You solved a scaling problem you probably did not have.

For many SaaS applications, a modular monolith is a better starting point.

For example:

src/
    Modules/
        Accounts/
        Projects/
        Billing/
        Notifications/
        Reporting/

Each module contains its own:

Controllers
Services
Models
Repositories
Events
Jobs
Policies
Tests

You receive many benefits of service separation without distributed-system complexity.

Later, if billing becomes computationally expensive or organizationally independent, you can extract it.

Modular Monolith

      ↓

Identify scaling boundary

      ↓

Extract Billing Module

      ↓

Billing Service

AI is extremely useful during this extraction because clear boundaries allow it to identify dependencies and migrate them systematically.

The important decision is establishing those boundaries early.

Create an Architecture Contract for AI

One of the biggest improvements you can make to AI-assisted development is creating repository-level engineering instructions.

OpenAI specifically recommends using AGENTS.md to supply persistent context to Codex. OpenAI's guidance notes that these files can document naming conventions, business logic, dependencies, and repository-specific information that agents cannot reliably infer from source code alone.

GitHub Copilot similarly supports repository-wide instructions, path-specific instructions, and AGENTS.md files.

This changes how we should think about documentation.

Documentation is no longer only for developers.

It can function as executable context for engineering agents.

A useful file could look like this:

# Architecture

This application uses a modular monolith.

Modules:

- Accounts
- Projects
- Billing
- Notifications
- Reporting

Modules must not directly access another module's database models.

Cross-module communication must use application services or domain events.

# Controllers

Controllers are responsible only for:

- request validation
- authorization
- calling application services
- returning responses

Never place business logic inside controllers.

# Database

All list endpoints must support pagination.

Avoid queries inside loops.

Use eager loading when relationships are required.

All new queries on high-volume tables must consider indexes.

# Jobs

External API calls should execute asynchronously unless an immediate response is required.

Jobs must be safe to retry where possible.

# Testing

All business logic requires unit or integration tests.

Every bug fix requires a regression test.

Run:

npm test

before completing any task.

# Security

Never expose database IDs when public UUIDs are available.

Never log passwords, tokens, secrets, or payment credentials.

Now imagine five AI agents working on different parts of the application.

Without this document, each agent may invent its own conventions.

With it, you have dramatically increased architectural consistency.

Give AI Constraints, Not Just Requirements

Compare these two prompts.

Weak prompt

Create an endpoint for creating orders.

AI has to decide:

validation
authorization
architecture
transaction handling
event handling
error handling
testing
response structure

Different runs may produce completely different solutions.

Now consider:

Implement POST /api/orders.

Requirements:

- authenticated users only
- use CreateOrderRequest for validation
- controller must contain no business logic
- business logic belongs in OrderService
- wrap inventory reservation and order creation in a database transaction
- dispatch OrderCreated only after successful persistence
- duplicate requests with the same idempotency key must not create multiple orders
- return OrderResource
- add integration tests
- follow the existing CreateInvoice implementation

The second prompt does something important.

It reduces the AI's decision surface.

This is one of the biggest secrets of scalable AI-assisted development.

The more architectural decisions you encode into the system, the fewer architectural decisions AI has to invent.

Think in Invariants

Strong systems are built around invariants.

An invariant is something that must always remain true.

For an e-commerce platform:

stock >= 0

For financial software:

total debits = total credits

For a subscription system:

a customer cannot have two active subscriptions
for the same plan unless explicitly allowed

For multi-tenant SaaS:

a user from Tenant A must never access Tenant B's data

AI should know these rules.

A repository might contain:

## Critical Domain Invariants

1. Inventory must never become negative.
2. Payment callbacks may be delivered multiple times.
3. Tenant data must always be scoped by tenant_id.
4. Subscription state changes must go through SubscriptionService.
5. Paid invoices cannot be deleted.

Now an agent modifying the system has significantly more useful context than one merely reading database schemas.

Design the Database Before Asking AI to Generate Models

AI coding tools make schema generation extremely convenient.

That convenience can hide bad database design.

Imagine asking:

Create tables for an e-commerce system.

You might receive:

users
products
orders
order_items
payments

Everything looks fine.

But scalable database design requires asking deeper questions.

For orders, for example:

How many rows might this table contain?

How will orders be queried?

Can orders change after payment?

Should customer information be snapshotted?

How are refunds represented?

How are currencies handled?

What indexes are necessary?

Are IDs sequential or public?

Do we need tenant partitioning?

How long must records be retained?

The important insight is:

Database schemas encode product assumptions.

AI can generate migrations quickly, but you still need to determine those assumptions.

Teach AI to Think About Query Complexity

A classic AI-generated implementation might look like:

$orders = Order::all();

foreach ($orders as $order) {
    echo $order->customer->name;
}

It works perfectly with twenty orders.

With 100,000 orders, things become different.

Good architecture should explicitly instruct agents to consider:

pagination
indexes
N+1 queries
selective columns
aggregation cost
query plans
memory usage
sorting
filtering

Instead of:

Order::all();

you might use:

Order::query()
    ->with('customer:id,name')
    ->latest()
    ->paginate(50);

But even that may eventually require optimization.

A scalable engineering workflow tells AI to inspect the actual query pattern rather than blindly copying ORM conventions.

Put Indexing Into the Feature Design Process

Suppose your application frequently executes:

SELECT *
FROM orders
WHERE tenant_id = ?
AND status = ?
ORDER BY created_at DESC
LIMIT 50;

At sufficient scale, indexing becomes part of the feature.

You might need:

CREATE INDEX idx_orders_tenant_status_created
ON orders (tenant_id, status, created_at);

The important point is not the exact index.

The important point is that AI should be instructed to ask:

How will this data be accessed?

instead of only:

What columns should this table contain?

Avoid Premature Distributed Architecture

Developers frequently associate scalability with microservices.

That is a mistake.

Consider:

Application
    |
    ├── User Service
    ├── Product Service
    ├── Order Service
    ├── Payment Service
    ├── Notification Service
    └── Analytics Service

This architecture may scale beautifully.

It can also become a nightmare.

Every network boundary introduces potential:

timeout
retry
partial failure
version mismatch
latency
authentication failure
message duplication
deployment coordination

Distributed systems require explicit failure design.

AWS's current reliability guidance, for example, recommends making mutating operations idempotent so retries do not create unintended duplicate effects. It also recommends controlling retries with techniques such as exponential backoff, jitter, and retry limits.

AI can generate REST clients in seconds.

It cannot eliminate network uncertainty.

So extract services when there is a reason.

Good reasons include:

independent scaling requirements
strong team ownership boundaries
security isolation
fundamentally different workloads
independent deployment requirements
technological constraints

"Microservices are scalable" is not enough.

Use Queues to Separate User Latency From Heavy Work

Suppose a user uploads a video.

A naive request might do this:

Upload
  ↓
Generate thumbnail
  ↓
Transcode video
  ↓
Analyze metadata
  ↓
Send notification
  ↓
Return HTTP response

The user waits for everything.

A scalable design looks different.

Upload
  ↓
Save metadata
  ↓
Queue processing
  ↓
Return response

      Background Workers
             |
      ┌──────┼───────┐
      ▼      ▼       ▼
 thumbnail transcode analysis

AI is particularly effective at implementing workers and background jobs once the architecture is defined.

The developer decides:

what must happen synchronously?
what can happen asynchronously?
what can fail independently?
what must be retried?

AI implements those decisions.

Make Background Jobs Idempotent

This deserves special attention.

Consider:

class ChargeCustomer
{
    public function handle()
    {
        PaymentGateway::charge(
            $this->customer,
            $this->amount
        );
    }
}

What happens if:

payment succeeds
↓
worker crashes
↓
job remains unacknowledged
↓
queue retries
↓
customer charged again

The code looked correct.

The system was not correct.

A scalable system assumes work can execute more than once.

The job might instead use an idempotency key:

PaymentGateway::charge(
    customer: $this->customer,
    amount: $this->amount,
    idempotencyKey: $this->paymentAttemptId
);

AWS describes this principle explicitly: retryable operations should avoid additional side effects when the same request is processed again.

Your AI instructions should therefore contain rules such as:

All payment jobs must be idempotent.

All webhook handlers must tolerate duplicate delivery.

All external API retries must consider whether the operation is safe to repeat.

These small instructions can prevent extremely expensive bugs.

Use Caching Intentionally

Another common AI response to performance problems is:

Add Redis caching.

That is not a caching strategy.

Before caching something, answer:

What are we caching?

Why?

How long?

What invalidates it?

Can stale data be returned?

What happens if Redis is unavailable?

Suppose this query runs constantly:

SELECT COUNT(*)
FROM orders
WHERE tenant_id = ?
AND status = 'pending';

You might cache:

tenant:42:pending_orders_count

But then:

When should it be invalidated?

After an order is created?

After status changes?

After cancellation?

After import?

After payment?

Cache invalidation is part of the architecture.

AI can implement the invalidation hooks quickly, but humans need to define the consistency expectation.

Build Stable Interfaces Between Components

Good scalability depends heavily on contracts.

Suppose the billing module exposes:

interface BillingService
{
    public function subscribe(
        User $user,
        Plan $plan
    ): Subscription;
}

Other modules depend on this interface.

They should not depend on:

StripeSubscriptionRepository
StripeWebhookParser
StripePaymentIntentService
StripeCustomerModel

Why?

Because implementation details spread coupling.

If every module directly accesses another module's internals, AI-generated changes become dangerous.

A small implementation change can trigger modifications throughout the codebase.

Stable contracts reduce the blast radius.

AI Works Best With Strong Local Patterns

One of OpenAI's recommendations for Codex is to structure tasks similarly to GitHub issues and point agents toward existing implementations when relevant.

For example:

Implement password reset rate limiting.

Follow the same architecture used by
LoginRateLimiter.

Files to inspect:

src/Auth/LoginRateLimiter.php
src/Auth/LoginController.php
tests/Auth/LoginRateLimiterTest.php

This is dramatically safer than:

Add rate limiting.

The first prompt gives the agent a local architectural reference.

The second asks it to invent architecture.

That suggests a powerful rule:

Create one excellent implementation of every important pattern, then tell AI to follow it.

Examples include:

CreateOrder
UpdateSubscription
UploadFile
HandleWebhook
ProcessPayment
ExportReport
SendNotification

Once those patterns exist, development becomes pattern replication rather than architecture invention.

Tests Become More Important in the AI Era, Not Less

There is a common temptation:

AI wrote the code.
AI reviewed the code.
Therefore the code is probably correct.

This is dangerous.

AI can produce an implementation and then confidently approve its own incorrect assumptions.

The scalable approach is automated verification.

Think of this relationship:

AI speed increases
       ↓
number of changes increases
       ↓
verification requirements increase

If an engineering team moves from ten changes per day to fifty, manual verification becomes increasingly insufficient.

Use Multiple Layers of Testing

A scalable system should have several verification layers.

Unit tests

Validate isolated business rules.

public function test_discount_cannot_exceed_order_total()
{
    $order = new Order(total: 100);

    $this->expectException(
        InvalidDiscountException::class
    );

    $order->applyDiscount(120);
}

Integration tests

Validate component interactions.

Database
Queue
Cache
External service adapters

API tests

Validate actual contracts.

POST /api/orders

201
{
    "id": "...",
    "status": "pending"
}

End-to-end tests

Validate critical user journeys.

Register
↓
Create organization
↓
Subscribe
↓
Create project
↓
Invite teammate

AI can generate all of these.

The important part is making tests a required deliverable.

Instead of:

Implement this feature.

write:

Implement this feature.

Add unit tests for business rules.

Add integration tests for persistence.

Add API tests for authorization and validation.

Run the relevant suite and fix failures before completing the task.

Every Bug Should Produce a Regression Test

This is one of the most effective rules you can introduce.

Suppose production reveals:

Users can redeem the same coupon twice
when two requests arrive simultaneously.

Do not ask AI:

Fix duplicate coupon redemption.

Ask:

Reproduce the duplicate coupon redemption bug
with a failing test.

Then fix the implementation.

The test must pass after the fix.

Now your repository gains permanent knowledge.

The bug becomes:

production incident
      ↓
regression test
      ↓
architectural knowledge

Over time, the test suite becomes a memory system.

This is especially valuable for AI agents that did not participate in earlier incidents.

Use Static Analysis as an Architectural Guardrail

AI agents are excellent at generating code.

Static analyzers are excellent at refusing certain classes of bad code.

Combine them.

Examples include:

TypeScript compiler
PHPStan
Psalm
ESLint
Ruff
mypy
SpotBugs
SonarQube
ArchUnit

Suppose your architecture says:

Domain code cannot depend on HTTP controllers.

Do not leave this entirely in documentation.

Where possible, enforce it.

For example:

Domain
   X
Controllers

If an agent violates the rule, CI should fail.

The ultimate scalable AI workflow is not:

Tell AI what to do correctly.

It is:

Tell AI what to do
+
automatically reject invalid solutions.

Treat CI as the Gatekeeper

The development process should look something like:

                AI Agent
                   |
                   ▼
               Code Change
                   |
                   ▼
        ┌─────────────────────┐
        │         CI          │
        ├─────────────────────┤
        │ Formatting          │
        │ Linting             │
        │ Static analysis     │
        │ Unit tests          │
        │ Integration tests   │
        │ Architecture tests  │
        │ Security checks     │
        │ Build               │
        └──────────┬──────────┘
                   │
                  pass
                   │
                   ▼
                Review

The stronger the pipeline becomes, the more safely AI can operate autonomously.

Observability Is Part of Scalability

Suppose AI helps you build an API handling 20,000 requests per minute.

Then customers begin reporting:

"Sometimes checkout takes 12 seconds."

What do you do?

If the application only logs:

Something went wrong

you have a problem.

Scalable systems require observability.

At minimum, consider:

Structured logs

Instead of:

Payment failed

log something structured:

{
  "event": "payment_failed",
  "payment_id": "pay_123",
  "order_id": "ord_456",
  "provider": "stripe",
  "error_code": "timeout",
  "duration_ms": 5021
}

Metrics

Track:

requests/sec
error rate
latency
database connections
queue depth
job failure rate
cache hit ratio
CPU
memory
external API latency

Tracing

A request might travel through:

API
 ↓
Order Service
 ↓
Payment Service
 ↓
Database
 ↓
Message Queue

Distributed tracing helps identify which stage consumed time.

The critical point is that observability should not be added after the system becomes large.

Build it while the architecture is still understandable.

Give AI Access to Operational Context Carefully

AI can help investigate production issues when given:

logs
stack traces
metrics
query plans
deployment diffs

For example:

p95 API latency increased from 180 ms to 1.8 seconds
after deployment 2026-08-07. Analyze these traces and
identify likely regressions.

This is far more effective than:

My application is slow. Fix it.

AI becomes powerful when provided evidence.

The general principle applies everywhere:

Context quality determines AI engineering quality.

Design for Horizontal Scaling

Suppose one application instance handles:

500 requests/second

Eventually you need:

Server A
Server B
Server C
Server D

behind a load balancer.

The application should therefore avoid storing critical state in local process memory.

Bad:

Server A memory:
user_123_session

If the next request reaches Server B:

session missing

Better:

                Load Balancer
                     |
        ┌────────────┼────────────┐
        ▼            ▼            ▼
     Server A     Server B     Server C
        │            │            │
        └────────────┼────────────┘
                     ▼
               Shared Session
                  Storage

Common choices include:

Redis
database-backed sessions
signed stateless tokens

This architectural rule should be documented for AI:

Application instances must remain stateless.

Do not introduce process-local state required across requests.

Now an agent writing features is less likely to accidentally undermine horizontal scalability.

Separate Storage Concerns

At small scale, developers often put everything into the relational database.

For example:

users
orders
sessions
logs
notifications
files
analytics

This can work initially.

As workloads grow, storage systems should match access patterns.

For example:

Transactional data
→ PostgreSQL / MySQL

Cache
→ Redis

Object files
→ S3-compatible storage

Search
→ OpenSearch / Elasticsearch

Analytics
→ analytical database or warehouse

Events
→ Kafka / queue system

Do not introduce all of these on day one.

But design interfaces that allow evolution.

For file uploads, for example, do not scatter:

file_put_contents(...)

throughout the application.

Create:

interface FileStorage
{
    public function put(
        string $path,
        mixed $content
    ): string;
}

Today:

LocalFileStorage

Tomorrow:

S3FileStorage

The system evolves without rewriting every feature.

AI Makes Refactoring Economically Different

Historically, large refactors were expensive because someone had to:

find references
change interfaces
update implementations
modify tests
update documentation
fix compilation errors

Coding agents can now automate a large portion of this mechanical work.

OpenAI describes internal teams using Codex for large-codebase refactoring, performance optimization, test coverage improvements, and other engineering work.

This means architecture can be more evolutionary than before.

You do not need to perfectly predict the next five years.

Instead:

choose simple architecture
       ↓
create strong boundaries
       ↓
measure the system
       ↓
identify pressure points
       ↓
refactor deliberately

AI reduces the cost of the last step.

It does not remove the need for the first four.

Keep Functions and Modules Small Enough to Understand

AI can produce huge implementations because generating code is cheap.

This sometimes results in:

public function processOrder()
{
    // validation
    // inventory check
    // customer lookup
    // discount calculation
    // tax calculation
    // payment
    // database updates
    // email
    // analytics
    // webhook
    // notification
    // logging
}

A 500-line method may technically work.

It is still architectural debt.

Split responsibilities:

OrderProcessor
├── InventoryReservation
├── PricingCalculator
├── TaxCalculator
├── PaymentProcessor
├── OrderRepository
└── OrderEventPublisher

But avoid the opposite extreme too.

AI can also generate abstraction explosions:

OrderCreatorInterface
DefaultOrderCreator
OrderCreationManager
OrderCreationCoordinator
OrderCreationFactory
OrderCreationContext
OrderCreationProvider

for something that required twenty lines.

Scalable architecture is not maximum abstraction.

It is the right abstraction at the right boundary.

Make AI Explain Before It Changes Critical Systems

For dangerous or high-impact changes, use an analysis-first workflow.

Instead of:

Optimize our checkout database queries.

use:

Analyze checkout database behavior.

Do not modify code yet.

Identify:

1. expensive queries
2. N+1 patterns
3. missing indexes
4. unnecessary writes
5. transaction boundaries
6. potential race conditions

Propose changes with expected benefits and risks.

Then review the plan.

Then:

Implement items 1, 2, and 4.

Do not change the transaction model yet.

This creates an engineering loop:

Explore
   ↓
Understand
   ↓
Plan
   ↓
Review
   ↓
Implement
   ↓
Verify

OpenAI similarly recommends beginning with an ask or exploration mode for many Codex workflows rather than immediately requesting modifications.

Break Large Features Into Vertical Slices

Avoid prompts like:

Build the entire marketplace system.

Instead:

Phase 1
Vendor registration

Phase 2
Product creation

Phase 3
Product publishing

Phase 4
Checkout

Phase 5
Commission calculation

Phase 6
Vendor payouts

Even better, make each phase independently testable.

For example:

Vendor registration

Requirements:
- user can apply
- application status starts pending
- admin can approve
- approval creates vendor profile
- operation must be transactional
- duplicate approval must not duplicate profile
- audit event must be recorded

Now the AI has a well-defined engineering problem.

Use ADRs for Important Architecture Decisions

Architecture Decision Records are extremely useful in AI-assisted projects.

Suppose you choose PostgreSQL rather than MongoDB for your transactional system.

Create:

docs/adr/001-use-postgresql.md

Example:

# ADR 001: Use PostgreSQL as Primary Database

## Context

The application requires:

- relational transactions
- complex reporting
- financial consistency
- strong foreign-key relationships

## Decision

Use PostgreSQL as the primary transactional database.

## Consequences

Benefits:

- strong transactional guarantees
- mature relational capabilities
- rich indexing
- reliable reporting

Trade-offs:

- schema migrations must be managed
- horizontal write scaling may require future work

## Revisit When

- write throughput exceeds current architecture
- geographically distributed writes become necessary

Now six months later, an AI agent does not recommend MongoDB simply because a particular feature contains flexible JSON.

It can understand why PostgreSQL exists.

Architecture documentation becomes institutional memory.

Document the "Why", Not Just the "What"

Bad documentation:

We use Redis.

Better:

Redis stores short-lived cache entries and distributed locks.

Redis must not be the authoritative source for billing data.

If Redis is unavailable, critical transactional operations should remain correct, although performance may degrade.

That second version tells an agent how the technology fits into the architecture.

Security Needs Hard Boundaries

AI generates code quickly.

Security mistakes also scale quickly.

Repository rules should explicitly address:

authentication
authorization
tenant isolation
input validation
secret handling
logging
SQL injection
file uploads
webhooks
rate limiting
encryption

For example:

Never trust tenant_id supplied by the client.

Determine tenant context from authenticated membership.

Every tenant-owned query must explicitly scope by tenant.

That rule can prevent an entire class of vulnerabilities.

For external callbacks:

All webhook endpoints must verify provider signatures before processing payloads.

For secrets:

Never hardcode credentials.

Never log authorization headers.

Never commit .env files.

Do not expect AI to infer your threat model.

Encode it.

Review AI Code Differently

Traditional code review asks:

Is this code correct?

AI-assisted code review needs additional questions.

Does the code follow existing architecture?

AI frequently produces locally correct but globally inconsistent code.

Did it introduce a new pattern unnecessarily?

For example, perhaps the repository already has:

OrderRepository

and AI creates:

OrderDataAccessor

for the same responsibility.

Did it duplicate existing functionality?

Search the repository.

Are failure scenarios handled?

Especially:

timeouts
retries
duplicate requests
partial writes
concurrency
network failures

Are queries scalable?

Inspect loops and relationship loading.

Are transactions correct?

AI sometimes places too much inside a transaction or not enough.

Is observability sufficient?

Can the feature be debugged in production?

Did tests verify behavior or merely implementation?

This distinction matters.

Never Blindly Accept Large AI Diffs

If an AI agent changes:

47 files
3,200 lines

for a relatively small feature, investigate.

Large diffs hide mistakes.

Ask the agent:

Explain why each changed file is necessary.

Identify changes that can be removed without affecting
the requested functionality.

Then reduce the change.

AI code is cheap.

Code ownership is not.

Every generated line becomes something your team potentially maintains for years.

Use AI to Delete Code Too

One of the healthiest uses of AI is identifying unnecessary complexity.

Prompt:

Analyze this module for:

- duplicate abstractions
- dead code
- redundant wrappers
- unnecessary interfaces
- duplicated validation
- unused dependencies

Propose simplifications without changing behavior.

A scalable codebase is often one that contains less code, not more.

Design an AI-Friendly Repository

A repository that works well with AI often has a predictable structure.

For example:

project/
├── AGENTS.md
├── README.md
├── docs/
│   ├── architecture.md
│   ├── domains.md
│   ├── database.md
│   ├── security.md
│   └── adr/
├── src/
│   ├── Accounts/
│   ├── Billing/
│   ├── Projects/
│   └── Notifications/
├── tests/
├── scripts/
└── .github/
    └── workflows/

The repository itself communicates its architecture.

Then AGENTS.md might say:

Before implementing changes:

1. Read docs/architecture.md.
2. Inspect the closest existing implementation.
3. Do not create new architectural patterns without justification.
4. Add tests for behavioral changes.
5. Run the relevant test suite.
6. Run static analysis.
7. Summarize architectural impact.

GitHub's documentation similarly recommends repository instructions that explain project structure, coding conventions, test frameworks, and build/run procedures.

Create Standard Commands

Agents perform much better when they do not need to discover basic development commands.

For example:

make setup
make dev
make test
make lint
make analyze
make build

or:

{
  "scripts": {
    "dev": "...",
    "test": "...",
    "lint": "...",
    "typecheck": "...",
    "build": "..."
  }
}

Your agent instructions can simply state:

After changes run:

npm run lint
npm run typecheck
npm test
npm run build

OpenAI notes that coding agents perform better when repositories have configured development environments, reliable tests, and clear documentation.

The less time an AI agent spends guessing how your project works, the more time it can spend solving the actual problem.

A Practical AI-Assisted Development Workflow

Here is a workflow I would recommend for building serious software with AI.

Step 1: Describe the product

Write:

What are we building?
Who uses it?
What problem does it solve?

Example:

Multi-tenant project management SaaS for agencies.

Organizations contain users and projects.

Customers subscribe to plans with usage limits.

Step 2: Define expected scale

Do not say:

It should scale.

Write assumptions.

Initial:
1,000 organizations
10,000 users

Expected:
50,000 organizations
500,000 users
50 million tasks

Peak API traffic:
2,000 requests/second

These estimates do not need to be perfect.

They force architectural reasoning.

Step 3: Identify domains

Accounts
Organizations
Projects
Billing
Notifications
Reporting

Define ownership.

Step 4: Establish architectural rules

For example:

Modular monolith.

Modules communicate through public services/events.

Controllers contain no business logic.

Database access remains inside owning modules.

Background work runs through queues.

Application nodes remain stateless.

Step 5: Define critical invariants

Tenant data never crosses tenants.

Payment webhook processing is idempotent.

Usage counters cannot become negative.

Paid invoices cannot be modified.

Step 6: Create AI instructions

Add:

AGENTS.md

or the repository instruction format supported by your coding environment.

Document:

architecture
commands
patterns
testing
security
database conventions

Step 7: Build one module properly

Do not generate the whole product at once.

Implement:

Accounts

carefully.

Use it to establish patterns.

Step 8: Let AI replicate proven patterns

Now tell AI:

Implement Project membership following
the same layering, validation, testing,
and authorization approach used by
Organization membership.

This is where AI becomes extraordinarily productive.

Step 9: Automate verification

CI should enforce:

format
lint
types
architecture
tests
build
security

Step 10: Measure before optimizing

Deploy.

Measure:

latency
throughput
query times
queue depth
cache performance
error rates
resource usage

Then optimize actual bottlenecks.

Do not ask AI to solve hypothetical scale problems before evidence exists.

Example: Building a Scalable Order System With AI

Consider an e-commerce order service.

A simplistic flow:

POST /orders
     |
     ▼
Create order
     |
     ▼
Charge card
     |
     ▼
Send email

We can improve it.

Client
  |
  ▼
POST /orders
  |
  ▼
API
  |
  ▼
OrderService
  |
  ├── Validate inventory
  ├── Calculate price
  ├── Create order
  └── Commit transaction
            |
            ▼
       OrderCreated
            |
      ┌─────┼─────────┐
      ▼     ▼         ▼
  Payment  Email   Analytics
   Worker  Worker    Worker

Now specify invariants:

Order creation is idempotent.

Inventory cannot become negative.

Order prices are snapshotted.

Payment failure does not delete the order.

Email failure does not affect payment.

Webhook processing supports duplicate events.

Then instruct AI:

Implement CreateOrder.

Architecture:

- controller handles HTTP only
- business logic belongs in CreateOrderService
- use a transaction for inventory reservation and order persistence
- use idempotency keys
- dispatch OrderCreated after persistence
- payment execution must happen asynchronously
- add concurrency tests around inventory
- add duplicate-request tests
- add structured logging

Now AI is not designing the system.

It is implementing a system you designed.

That distinction is enormous.

What AI Should Do in a Scalable Engineering Team

AI is particularly good at:

Repository exploration

Explain how payments currently work.

Pattern discovery

Find all implementations of idempotency handling.

Code generation

Implement this service following the existing pattern.

Testing

Generate edge-case tests for this state machine.

Refactoring

Move this domain logic from controllers into services
without changing API behavior.

Performance investigation

Analyze these database queries for N+1 patterns.

Documentation

Document the billing workflow based on the implementation.

Migration work

Update all call sites to use the new interface.

Review

Review this diff specifically for concurrency,
authorization, and database performance issues.

These tasks benefit enormously from AI.

What Humans Should Continue Owning

Humans should remain responsible for:

product goals
architecture
trade-offs
domain boundaries
risk tolerance
security model
data ownership
consistency requirements
operational strategy
cost constraints

AI can advise on all of these.

But someone needs to own the decision.

The Biggest Mistake: Optimizing for AI Output Instead of System Quality

AI produces visible progress.

You prompt:

Build notification system

and suddenly:

14 files created
2 migrations
6 services
3 jobs
4 tests

It feels productive.

But lines of code are not progress.

Architecture is not measured by how much software exists.

The relevant questions are:

Does this solve the problem?

Is the boundary correct?

Can this be changed later?

Can it fail safely?

Can it be observed?

Can it scale?

Can another engineer understand it?

Can an AI agent understand it six months later?

Sometimes the best AI-assisted implementation is fifty lines.

A Better Mental Model for AI-Assisted Software Engineering

Traditional development looked roughly like:

Developer
   ↓
Design
   ↓
Code
   ↓
Test
   ↓
Deploy

AI-assisted engineering increasingly looks like:

                    Human Engineer
                         |
             Architecture + Constraints
                         |
                         ▼
                    AI Agents
                         |
             ┌───────────┼────────────┐
             ▼           ▼            ▼
          Coding       Testing      Refactoring
             │           │            │
             └───────────┼────────────┘
                         ▼
                Automated Guardrails
                         |
       ┌─────────────────┼──────────────────┐
       ▼                 ▼                  ▼
    Tests          Static Analysis      Security
       │                 │                  │
       └─────────────────┼──────────────────┘
                         ▼
                    Human Review
                         |
                         ▼
                    Production
                         |
                         ▼
                   Observability
                         |
                         ▼
                    Feedback

That feedback goes back into:

tests
architecture
documentation
agent instructions

The system becomes easier to develop over time.

The Real Scalability Advantage of AI

AI's biggest impact on scalable software may not be code generation.

It may be reducing the cost of maintaining architectural consistency.

Imagine an engineer saying:

Find every endpoint that returns an unpaginated collection.

An agent can search the repository.

Then:

Identify all jobs that perform non-idempotent external API calls.

Then:

Find modules that directly access Billing models.

Then:

Find database queries inside loops.

Then:

Generate regression tests for these cases.

This turns architectural maintenance from an occasional manual audit into something much closer to continuous inspection.

That is extremely powerful.

Five Principles I Would Use on Every AI-Assisted Project

If I had to reduce this entire approach to five rules, they would be these.

1. Architecture before generation

Do not allow implementation speed to replace design.

Understand:

boundaries
data
failure modes
scale
ownership

before generating large amounts of code.

2. Constraints before prompts

Give AI a system of rules.

Do not repeatedly explain your architecture in every conversation.

Encode it in the repository.

3. Patterns before autonomy

Build one good example.

Then let agents repeat the pattern.

Consistency beats creativity in most production codebases.

4. Verification before trust

AI output is untrusted until verified.

Use:

tests
types
static analysis
CI
architecture rules
security checks

5. Measurement before optimization

Do not build Kafka because somebody said you might eventually have millions of users.

Measure the system.

Optimize the bottleneck that actually exists.

Final Thoughts

AI has made writing software dramatically cheaper.

That does not make software engineering less important.

It makes engineering discipline more important.

When generating code required significant human effort, development speed naturally limited how quickly complexity could accumulate.

AI removes part of that limitation.

A team can now produce enormous amounts of code very quickly.

Without strong architecture, that becomes enormous amounts of technical debt very quickly.

The teams that benefit most from AI will therefore not necessarily be those that generate the most code.

They will be the teams that create environments where AI can safely generate code.

They will build clear module boundaries.

They will define invariants.

They will document architectural decisions.

They will design retry-safe operations.

They will automate tests and static analysis.

They will build observable systems.

They will measure real bottlenecks.

They will maintain repositories that both humans and AI agents can understand.

And they will use AI for what it is exceptionally good at: accelerating implementation, exploration, testing, refactoring, investigation, and repetitive engineering work.

The goal is not:

AI writes my software.

A much better goal is:

I design a system where AI can safely help build,
test, evolve, and operate the software.

That is the difference between using AI to generate code and using AI to build scalable software.

Bruno: The Git-Native API Client Developers Should Try

Moniruzzaman Saikat — Mon, 03 Aug 2026 16:09:15 +0000

Modern API development requires more than a tool that can send HTTP requests.

Developers need API collections that can be reviewed, versioned, tested, shared, and executed inside CI pipelines. However, many API clients treat collections as data stored inside their own platform.

Bruno takes a different approach.

Bruno is an open-source, local-first, and Git-native API client. Instead of hiding API collections inside a cloud workspace, Bruno stores them as readable files on your filesystem.

That simple decision makes Bruno fit naturally into a developer's existing workflow.

What Is Bruno?

Bruno is a desktop API client for developing and testing APIs.

You can use it to work with:

REST APIs
GraphQL APIs
Authentication flows
Environment variables
Request scripts
Response tests
API documentation
Automated collection runs

It covers many workflows developers already use tools like Postman or Insomnia for.

The major difference is how Bruno stores and manages API collections.

Your requests live inside regular folders and text files. You can open them in an editor, commit them to Git, review changes in pull requests, and keep them beside your application code.

Why Git-Native API Collections Matter

Imagine that your backend repository contains the following structure:

my-api/
├── app/
├── database/
├── routes/
├── tests/
└── api-collection/
    ├── users/
    ├── authentication/
    ├── products/
    └── bruno.json

The API collection can be committed to the same repository as the application.

When a developer changes an endpoint, they can update the related Bruno request in the same branch.

A pull request can then contain:

Updated user registration validation
Updated registration API request
Added registration error tests
Updated API documentation

The backend implementation and its API examples remain synchronized.

This is much cleaner than updating code in Git while separately maintaining a collection inside an external cloud workspace.

Collections Are Readable Files

Bruno stores requests as plain-text files.

A simplified Bruno request may look similar to this:

meta {
  name: Get Current User
  type: http
  seq: 1
}

get {
  url: {{baseUrl}}/api/user
  body: none
  auth: bearer
}

auth:bearer {
  token: {{accessToken}}
}

tests {
  test("should return the authenticated user", function () {
    expect(res.status).to.equal(200);
  });
}

Because the request is text-based, it works well with:

Git diffs
Pull requests
Code reviews
Merge history
IDE search
Automated agents
Repository backups

You do not need a proprietary interface just to understand what changed.

Local-First by Design

Bruno runs locally and does not require an account for its normal open-source workflow.

Your requests, environments, scripts, and collections stay on your machine or inside repositories you control.

This is useful when working with:

Private APIs
Internal company services
Sensitive authentication flows
Client projects
Local development environments
Restricted enterprise networks

A local-first tool also avoids making your API workflow dependent on the availability of an external cloud platform.

Creating Your First Bruno Collection

After installing Bruno, create a new collection and select a directory on your filesystem.

For example:

projects/
└── inventory-api/
    └── bruno/

Create an environment containing variables such as:

vars {
  baseUrl: http://localhost:8000
  accessToken:
}

You can then create a login request:

POST {{baseUrl}}/api/login

With a JSON body:

{
  "email": "developer@example.com",
  "password": "password"
}

After receiving the response, you can save the token using a post-response script:

if (res.status === 200) {
  bru.setEnvVar("accessToken", res.body.token);
}

Other authenticated requests can reuse the value:

Authorization: Bearer {{accessToken}}

This creates a repeatable authentication workflow without manually copying tokens after every login.

Testing API Responses

Bruno supports response tests, allowing a collection to work as both documentation and executable validation.

For example:

test("status should be 200", function () {
  expect(res.status).to.equal(200);
});

test("response should contain a user", function () {
  expect(res.body).to.have.property("user");
});

test("user should have an email", function () {
  expect(res.body.user).to.have.property("email");
});

You can also validate response types:

test("products should be an array", function () {
  expect(res.body.products).to.be.an("array");
});

Or check business rules:

test("product stock should not be negative", function () {
  res.body.products.forEach(function (product) {
    expect(product.stock).to.be.at.least(0);
  });
});

These tests help catch API regressions before they reach production.

Environments and Variables

Most applications have multiple environments:

Local
Development
Staging
Production

Instead of duplicating requests, you can create environment-specific variables.

Local environment:

vars {
  baseUrl: http://localhost:8000
}

Staging environment:

vars {
  baseUrl: https://staging-api.example.com
}

Production environment:

vars {
  baseUrl: https://api.example.com
}

Your request remains unchanged:

GET {{baseUrl}}/api/products

You only switch the active environment.

Sensitive values such as API keys and access tokens should be stored separately from committed collection files.

Bruno automatically creates recommended Git ignore rules when creating collections, but developers should still review files before committing them.

Collaboration Through Git

A Bruno collection can be managed like any other source code directory.

Initialize Git:

git init

Add the collection:

git add .

Create a commit:

git commit -m "Add authentication API collection"

Connect it to a remote repository:

git remote add origin https://github.com/username/project-api.git
git push -u origin main

Team members can clone the repository and open the same collection in Bruno.

Changes can be reviewed using normal Git commands:

git diff
git status
git log

This gives API collections the same review process as application code.

Running Collections From the CLI

Bruno provides a command-line interface called Bruno CLI.

Install it using npm:

npm install -g @usebruno/cli

Navigate to the collection directory:

cd path/to/bruno-collection

Run the entire collection:

bru run

Run it with a selected environment:

bru run --env local

Run only a specific folder:

bru run users

You can also pass environment variables directly:

bru run --env local --env-var ACCESS_TOKEN=your-token

To run requests with selected tags:

bru run --tags=smoke,sanity

To exclude unfinished or skipped requests:

bru run --exclude-tags=skip,draft

This makes Bruno useful beyond manual API exploration.

Your collection can become part of your automated testing system.

Using Bruno in CI/CD

A simple CI workflow can install Bruno CLI and run an API collection after starting the application.

A simplified GitHub Actions example could look like this:

name: API Tests

on:
  push:
    branches:
      - main
  pull_request:

jobs:
  api-tests:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 22

      - name: Install Bruno CLI
        run: npm install -g @usebruno/cli

      - name: Run API tests
        working-directory: ./bruno
        run: bru run --env ci

For a real application, you would also start the backend service and database before executing the collection.

For example:

- name: Install backend dependencies
  run: composer install --no-interaction

- name: Prepare environment
  run: |
    cp .env.example .env
    php artisan key:generate
    php artisan migrate --force

- name: Start Laravel server
  run: php artisan serve --host=127.0.0.1 --port=8000 &

- name: Run Bruno tests
  working-directory: ./bruno
  run: bru run --env ci

Now every pull request can verify that important API endpoints still work.

Generating Test Reports

Bruno CLI supports report formats that can be used in automated pipelines.

Depending on your workflow, you can generate formats such as:

JSON
JUnit
HTML

JUnit output is especially useful because many CI platforms can display test results directly.

A collection can therefore serve several purposes:

Manual API exploration
Developer documentation
Regression testing
CI validation
Integration testing

This reduces the need to maintain separate API examples and testing assets.

Importing Existing Collections

Teams do not need to rebuild every request manually before trying Bruno.

Bruno supports importing collections from common formats and tools, including Postman collections.

A practical migration process is:

Export the existing collection.
Import it into Bruno.
Verify environment variables and authentication.
Review scripts and tests.
Store the new collection inside the project repository.
Commit it to Git.
Add CLI execution to CI.

Some tool-specific scripts may require adjustment, but importing provides a useful starting point.

API Documentation Inside the Collection

Bruno supports Markdown documentation at different levels, including:

Workspace
Collection
Folder
Request

You can document an authentication folder with information such as:

# Authentication

All protected endpoints require a bearer token.

## Login

Send the user's email and password to `/api/login`.

The response contains an access token that should be included in the
`Authorization` header for future requests.

Documentation stays close to the executable requests.

When an endpoint changes, developers can update the request, tests, and explanation together.

Bruno can also generate standalone HTML documentation from collections, making it possible to publish readable API references without maintaining a completely separate source.

Bruno 4 and AI Assistance

Bruno 4.0 introduced Bring Your Own Key AI capabilities.

Instead of forcing developers to use a fixed AI provider, Bruno supports OpenAI-compatible providers and custom model configurations.

Its AI features can assist with:

Writing request documentation
Generating scripts
Creating response tests
Reviewing changes
Working with the active request or collection
Providing scripting autocomplete

The Bring Your Own Key approach gives developers more control over the provider, model, and credentials they use.

Bruno also includes security controls that explain what context is shared with the selected AI provider.

AI assistance is most useful here when it improves the files developers already own instead of moving their entire API workflow into another closed platform.

Where Bruno Fits Best

Bruno is particularly suitable for teams that:

Already use Git for collaboration
Want collections stored beside application code
Prefer local-first development tools
Need readable API request files
Want API tests inside CI pipelines
Work with private or internal APIs
Want to avoid mandatory cloud accounts
Need an open-source API client
Use coding agents or IDE-based workflows

It is also a strong option for solo developers because collections can be backed up and shared through any Git repository.

Things to Consider

Bruno's workflow may feel different if your team is accustomed to browser-based collaboration.

Git-based collaboration assumes that team members understand concepts such as:

Repositories
Commits
Branches
Pull requests
Merge conflicts

This is usually not a major issue for engineering teams, but it can require onboarding for non-technical users.

Some advanced Git interface features and team capabilities are also associated with paid Bruno editions. You should compare the current editions before standardizing it across a larger organization.

The core open-source workflow, however, remains highly useful for individual developers and technical teams.

Bruno vs Traditional Cloud-Based API Clients

The main difference is not the request editor.

Most established API clients can send requests, manage environments, and execute tests.

The important difference is ownership and workflow.

A traditional cloud-based workflow often looks like this:

Application code -> Git repository
API collection -> External platform
Documentation -> Another platform
Automated tests -> Separate test suite

A Bruno-based workflow can look like this:

Application code -> Git repository
API collection -> Same Git repository
API documentation -> Same collection
API tests -> Same collection
CI execution -> Bruno CLI

This does not eliminate every tool, but it reduces fragmentation.

A Practical Project Structure

For a Laravel API, I would organize the project like this:

inventory-platform/
├── app/
├── database/
├── routes/
├── tests/
├── bruno/
│   ├── authentication/
│   │   ├── login.bru
│   │   ├── logout.bru
│   │   └── current-user.bru
│   ├── products/
│   │   ├── list-products.bru
│   │   ├── create-product.bru
│   │   └── update-product.bru
│   ├── orders/
│   │   ├── create-order.bru
│   │   └── get-order.bru
│   ├── environments/
│   ├── collection.bru
│   └── bruno.json
├── composer.json
└── README.md

Each backend feature should include:

Its implementation
Automated application tests
Bruno requests
Bruno response tests
Relevant API documentation

A feature is not complete until its executable API examples are updated.

Conclusion

Bruno is not interesting simply because it is another API client.

It is interesting because it treats API collections as part of the codebase.

Collections can be stored locally, reviewed through Git, executed through the command line, validated in CI, and edited with normal developer tools.

That makes the API workflow easier to own and maintain.

For developers who value local tools, open-source software, readable files, and Git-based collaboration, Bruno is worth testing on a real project.

You can explore it at usebruno.com and keep your first collection inside your next API repository.

React Native vs Flutter in 2026: Which One Should You Choose?

Moniruzzaman Saikat — Tue, 28 Jul 2026 14:50:16 +0000

Every year someone declares a winner in the React Native vs Flutter debate.

The reality is much simpler.

Neither framework is universally better. The right choice depends on your team, product, timeline, and long term goals.

After watching both ecosystems evolve, here is how I think about choosing between them in 2026.

React Native

React Native lets you build mobile applications using JavaScript or TypeScript with React.

If your team already builds web applications with React, the learning curve is relatively small.

Strengths

Excellent for React developers
Large ecosystem and community
Strong third party library support
Easier code sharing between web and mobile
Huge hiring pool

Challenges

Native modules are sometimes required
Performance can require additional optimization
Dependency compatibility occasionally becomes frustrating
Platform specific issues still exist

React Native is often the fastest path if your company already has experienced React engineers.

Flutter

Flutter uses Dart and renders its own UI instead of relying on native platform widgets.

That gives developers remarkable control over the user interface.

Strengths

Beautiful and consistent UI
Excellent animation support
High performance
Great developer tooling
Predictable rendering across Android and iOS

Challenges

Requires learning Dart
Larger application size
Smaller talent pool compared to React
Less code sharing with existing React web applications

Flutter shines when UI quality and consistency are top priorities.

Performance

For most business applications, users will not notice a meaningful difference.

Modern versions of both frameworks perform extremely well.

Performance only becomes a deciding factor for applications with:

Complex animations
Heavy graphics
Real time visual rendering
Large interactive interfaces

Even then, architecture matters more than the framework itself.

Developer Experience

React Native feels familiar if you already know JavaScript.

Flutter feels surprisingly productive once you become comfortable with Dart.

Both provide excellent hot reload capabilities, making development much faster than traditional native development.

Community

React Native has years of maturity and an enormous ecosystem.

Flutter continues to grow rapidly with excellent documentation and an active community.

Finding solutions online is easy with either framework.

Hiring Developers

This is where React Native still has an advantage.

JavaScript is one of the most widely used programming languages, making React Native developers easier to find.

Flutter developers are becoming more common every year, but experienced engineers are still less abundant in many regions.

When I Would Choose React Native

I would choose React Native when:

The company already uses React
Fast hiring is important
Code sharing with web applications matters
Existing JavaScript expertise is strong

When I Would Choose Flutter

I would choose Flutter when:

Pixel perfect UI is important
The product relies heavily on animations
Design consistency matters
Starting a completely new mobile project

The Bigger Picture

Frameworks change.

Programming languages evolve.

New tools appear every year.

The fundamentals remain the same.

A well designed architecture, clean code, thoughtful testing, and understanding your users will have a far bigger impact than choosing React Native or Flutter.

The best mobile applications are rarely successful because of the framework they use.

They succeed because they solve real problems.

Final Thoughts

Stop looking for the perfect framework.

Instead, choose the one that fits your team, your product, and your long term maintenance goals.

Both React Native and Flutter are capable of building excellent mobile applications in 2026.

The better choice is the one your team can build, maintain, and improve with confidence.

What would you choose for your next project in 2026? React Native or Flutter?

The Future of Software Engineering in the Age of AI

Moniruzzaman Saikat — Mon, 27 Jul 2026 16:57:39 +0000

Artificial intelligence is changing software engineering faster than most developers expected.

AI tools can already generate code, explain unfamiliar repositories, write tests, detect bugs, create documentation, and suggest architectural improvements. This has created an important question for software engineers:

What should developers learn and plan for if AI can write code?

The future of software engineering is not about competing with AI at typing speed. It is about becoming better at understanding problems, designing systems, validating decisions, and using AI responsibly.

AI Will Change the Developer Workflow

Traditional software development often follows this process:

Understand the requirement
Design the solution
Write the code
Test the implementation
Fix bugs
Deploy the application
Maintain the system

AI can assist in almost every step, but assistance is not the same as ownership.

An AI tool may generate a controller, database migration, API endpoint, React component, or unit test within seconds. However, it does not automatically understand the complete business context, long-term product direction, infrastructure limitations, security requirements, or user expectations.

The engineer still needs to decide:

Whether the generated solution is correct
Whether it follows the existing architecture
Whether it introduces security risks
Whether it can scale
Whether it is maintainable
Whether it solves the actual business problem

AI will reduce repetitive coding, but it will increase the importance of engineering judgment.

Coding Skills Will Still Matter

Some people believe developers will no longer need to understand programming because AI can generate code.

That is unlikely.

Developers who understand programming deeply will use AI more effectively than developers who only know how to request code.

Without technical knowledge, it becomes difficult to detect:

Incorrect assumptions
Hidden performance issues
Security vulnerabilities
Poor database queries
Unnecessary dependencies
Broken edge cases
Inconsistent architecture
Hallucinated libraries or methods

A developer should still understand data structures, algorithms, databases, networking, operating systems, debugging, testing, security, and software architecture.

The difference is that developers may spend less time writing basic boilerplate and more time reviewing, integrating, and improving generated solutions.

The Software Engineer Will Become a System Orchestrator

Future software engineers may work more like orchestrators.

Instead of manually implementing every small function, they may divide a large problem into smaller tasks and use multiple tools or agents to complete them.

For example, an engineer may ask AI to:

Analyze an existing repository
Propose a database structure
Generate an initial implementation
Write automated tests
Review the implementation for security issues
Create API documentation
Prepare deployment instructions

The engineer will then review the output, resolve conflicts, test the system, and make the final decisions.

This requires more than prompt writing. It requires the ability to structure work clearly and evaluate results accurately.

Problem Solving Will Be More Valuable Than Syntax

Programming syntax is becoming easier to access.

A developer can ask AI how to write a loop, create a Laravel relationship, build a React hook, configure Docker, or write a SQL query.

The more valuable skill is understanding what should be built.

A strong engineer should be able to answer questions such as:

What is the actual problem?
Who experiences the problem?
What are the constraints?
What is the simplest reliable solution?
What could fail?
What data should be stored?
What should not be stored?
What are the security risks?
How will the system be maintained?
How will success be measured?

AI can generate several solutions, but the engineer must choose the right one.

Software Architecture Will Become More Important

AI can produce working code that is locally correct but globally inconsistent.

For example, an AI-generated feature may work in isolation while violating the project's architectural standards. It may duplicate existing services, bypass authorization rules, introduce tight coupling, or create unnecessary database queries.

Future engineers will need strong architectural awareness.

Important areas include:

Modular design
Separation of concerns
Domain modeling
API design
Database design
Caching strategies
Event-driven systems
Distributed systems
Observability
Fault tolerance
Scalability
Maintainability

The ability to understand the whole system will become more valuable than the ability to generate individual files quickly.

Code Review Will Become a Core Skill

As AI-generated code increases, code review will become one of the most important engineering activities.

Developers will need to review code for:

Functional correctness
Security
Performance
Readability
Maintainability
Test coverage
Architectural consistency
Compliance requirements
Unexpected side effects

AI can also assist with code review, but human accountability remains necessary.

A useful future workflow may include multiple review stages:

AI generates the initial code
AI performs a first review
Automated tests and static analysis run
A developer reviews the implementation
The feature is tested against real requirements
The final change is approved

The engineer becomes responsible for validating machine-generated work rather than trusting it automatically.

Testing Will Be More Important, Not Less

AI can generate code quickly, which means teams may produce more code in less time.

More code also creates more opportunities for defects.

Testing must remain a major part of the development process.

Future engineers should understand:

Unit testing
Integration testing
End-to-end testing
Contract testing
Load testing
Security testing
Regression testing
Property-based testing

AI can help create test cases, but developers must ensure the tests represent meaningful behavior.

A generated test may confirm that the code behaves exactly as written while failing to verify whether the business requirement is correct.

The best engineers will use AI to increase test coverage without replacing critical thinking.

Security Knowledge Will Become Essential

AI-generated code can contain vulnerabilities.

It may create unsafe queries, expose sensitive information, use insecure authentication patterns, mishandle file uploads, or depend on outdated packages.

Software engineers need to understand common security risks, including:

SQL injection
Cross-site scripting
Cross-site request forgery
Broken access control
Insecure direct object references
Authentication weaknesses
Secrets exposure
Dependency vulnerabilities
Unsafe deserialization
Server-side request forgery

Developers must treat AI-generated code as untrusted until it has been reviewed and tested.

Security cannot be delegated completely to an AI assistant.

Domain Knowledge Will Differentiate Engineers

Generic coding knowledge is widely available through AI tools.

Domain knowledge is harder to replace.

An engineer who understands healthcare, finance, logistics, education, e-commerce, legal operations, manufacturing, or another specialized industry can make better product decisions.

Domain knowledge helps engineers understand:

Real user workflows
Industry terminology
Regulatory requirements
Operational risks
Common exceptions
Data sensitivity
Business priorities

A developer who understands both technology and the business domain will remain highly valuable.

Communication Skills Will Matter More

Software engineering has never been only about code.

Engineers communicate with clients, product managers, designers, testers, support teams, infrastructure teams, and other developers.

As AI handles more implementation work, human communication becomes even more important.

Future engineers should be able to:

Ask clear questions
Challenge unclear requirements
Explain technical decisions
Document assumptions
Describe risks
Present tradeoffs
Write useful specifications
Give and receive feedback
Coordinate across teams

Clear communication also improves AI output. A vague requirement usually produces a vague implementation.

Developers Should Learn How to Work With AI Tools

AI-assisted development should become a practical engineering skill.

Developers should learn how to:

Provide relevant project context
Break large tasks into smaller steps
Define clear constraints
Request explanations before implementation
Ask for multiple solution options
Generate and review tests
Compare architectural approaches
Verify generated APIs and libraries
Request security reviews
Use repository-level coding agents safely
Control which files an agent can modify
Review changes before committing them

The goal is not to accept every generated answer. The goal is to use AI as a productive collaborator while maintaining control.

Prompt Engineering Alone Is Not a Career Plan

Prompt engineering is useful, but it is not enough by itself.

Good prompts depend on good thinking.

A developer needs technical understanding to provide the correct context, identify missing information, define constraints, and evaluate the output.

Instead of focusing only on prompt tricks, engineers should improve:

Technical fundamentals
System design
Product thinking
Debugging
Testing
Security
Communication
Domain expertise
AI-assisted workflows

Prompting is one part of the process, not the entire profession.

Junior Developer Roles Will Change

AI may affect junior developers more quickly because many entry-level tasks involve repetitive implementation.

Examples include:

Generating CRUD modules
Writing basic tests
Fixing simple bugs
Creating documentation
Converting designs into components
Writing database migrations
Building standard API endpoints

These tasks will not disappear completely, but teams may expect junior developers to complete them faster with AI assistance.

Junior engineers should focus on understanding why the code works.

They should practice:

Reading existing codebases
Debugging without blindly copying solutions
Writing tests
Understanding database behavior
Learning version control
Reviewing AI-generated code
Explaining their decisions
Building complete projects
Deploying and maintaining applications

The ability to learn and reason will matter more than memorizing syntax.

Senior Engineers Will Also Need to Adapt

Senior engineers are not automatically protected from AI-driven changes.

A senior developer who refuses to use modern tools may become slower than a less experienced engineer who combines technical knowledge with effective AI usage.

Senior engineers should learn how to:

Design AI-assisted development workflows
Define repository rules
Review large generated changes
Protect architectural consistency
Improve team productivity
Establish AI security policies
Select appropriate tools
Mentor developers in responsible AI usage
Measure the actual value of AI adoption

Experience remains valuable, but it must be combined with adaptability.

A Practical Future Plan for Software Engineers

Software engineers can prepare for the AI-driven future with a structured plan.

1. Strengthen the Fundamentals

Learn programming deeply instead of depending entirely on frameworks.

Focus on:

Data structures
Algorithms
Databases
Networking
Operating systems
Object-oriented programming
Functional programming concepts
Concurrency
Memory management
Software design principles

Frameworks change, but fundamentals remain useful.

2. Master One Technical Stack

Avoid learning every new framework at a shallow level.

Choose one stack and understand it properly.

Learn:

Project structure
Dependency management
Authentication
Authorization
Database optimization
Background jobs
Caching
Testing
Deployment
Monitoring
Security

Deep knowledge makes it easier to evaluate AI-generated code.

3. Learn System Design

Study how complete systems are designed.

Start with:

REST APIs
Database indexing
Caching
Queues
File storage
Search systems
Notification systems
Rate limiting
Logging
Monitoring

Then move toward distributed systems, fault tolerance, scalability, and event-driven architecture.

4. Build Real Projects

Tutorial projects are useful, but real projects reveal deeper problems.

Build applications that include:

Multiple user roles
Permissions
Payments
Notifications
File uploads
Background jobs
Reports
Search
Audit logs
Automated tests
Production deployment

Use AI during development, but review and understand every important decision.

5. Improve Debugging Skills

AI can suggest solutions, but debugging still requires investigation.

Practice:

Reading stack traces
Inspecting logs
Reproducing bugs
Isolating variables
Checking database queries
Profiling performance
Using debuggers
Identifying race conditions
Testing assumptions

A developer who can find the actual cause of a problem will remain valuable.

6. Learn Security

Security should be part of everyday development.

Study secure authentication, authorization, input validation, data protection, dependency management, secrets handling, and common web vulnerabilities.

Review AI-generated code with a security-first mindset.

7. Learn AI-Assisted Development

Use AI for real engineering tasks.

Experiment with:

Code generation
Repository analysis
Refactoring
Test generation
Documentation
Bug investigation
SQL optimization
Architecture comparison
Code review
Migration planning

Track which tasks save time and which tasks require more manual correction.

8. Develop Product Thinking

Understand how software creates value.

Learn how to:

Identify user pain points
Prioritize features
Reduce unnecessary complexity
Validate ideas
Measure outcomes
Balance quality and delivery speed
Understand business constraints

The engineer who helps build the right product is more valuable than the engineer who only writes requested code.

9. Improve Communication

Practice writing technical documentation, architecture notes, issue descriptions, pull request summaries, and project proposals.

Learn to explain complex topics in simple language.

10. Build a Public Body of Work

Create evidence of your skills.

This may include:

Open-source contributions
Technical articles
Complete GitHub projects
Architecture case studies
Performance optimization reports
Security reviews
Developer tools
Libraries
Documentation improvements

A strong portfolio should show how you think, not only how much code you can generate.

Skills That May Become More Valuable

The following skills are likely to become increasingly important:

System design
Software architecture
Security engineering
Cloud infrastructure
DevOps
Observability
Data engineering
AI integration
Model evaluation
Product engineering
Technical leadership
Domain expertise
Code review
Testing strategy
Performance optimization

Developers do not need to master everything. They should combine strong fundamentals with one or two areas of deeper specialization.

Skills That May Become Less Differentiating

Some skills may remain useful while becoming less valuable as standalone abilities.

Examples include:

Memorizing syntax
Writing repetitive boilerplate
Building basic CRUD systems without deeper logic
Converting simple designs into static pages
Writing basic documentation manually
Creating simple unit tests
Copying solutions without understanding them

AI can perform many of these tasks quickly.

The developer must add value through reasoning, verification, integration, and ownership.

Will AI Replace Software Engineers?

AI is more likely to replace parts of software engineering work than the entire profession.

It may reduce the amount of manual effort required for many tasks. It may also allow smaller teams to build larger products.

However, software projects still require people who can:

Understand unclear requirements
Make technical decisions
Manage risk
Protect user data
Resolve production incidents
Coordinate teams
Balance business and engineering priorities
Take responsibility for outcomes

The role will change, but responsibility will remain human.

The Best Strategy Is Adaptation

Developers should not ignore AI, and they should not depend on it blindly.

The strongest approach is to combine human judgment with machine speed.

Use AI to:

Explore ideas faster
Reduce repetitive work
Generate initial implementations
Improve documentation
Expand test coverage
Analyze unfamiliar code
Compare possible solutions

Use engineering knowledge to:

Define the problem
Select the architecture
Verify correctness
Protect security
Test edge cases
Maintain quality
Make final decisions

The future belongs to engineers who can use AI without surrendering their judgment.

Conclusion

Software engineering is entering a new stage.

Writing code will remain important, but it will no longer be the only defining skill of a developer. The profession will place greater value on problem solving, architecture, testing, security, communication, domain knowledge, and responsible AI usage.

Developers should not ask whether AI will eliminate software engineering.

A more useful question is:

How can I become the engineer who knows what to build, how to validate it, and how to use AI to deliver it better?

That is the future plan worth following.

From Electron to Native Desktop Apps: How I Rebuilt TimoDesk for macOS and Windows

Moniruzzaman Saikat — Fri, 17 Jul 2026 18:15:44 +0000

From Electron to Native Desktop Apps: How I Rebuilt TimoDesk for macOS and Windows

Over the last month, I have spent most of my time rebuilding TimoDesk.

This was not a normal update or a small feature release. TimoDesk needed a complete desktop application rewrite.

The previous application was built with Electron and React. It worked well, but after running for long periods, we faced problems such as higher memory usage, larger application bundles, occasional performance issues, and an experience that did not always feel fully native.

Because TimoDesk is designed to run silently in the background for many hours, efficiency matters.

So I made a major decision.

I rebuilt the macOS application using Swift and the Windows application using .NET WPF.

Both applications are now in production.

Why This Was a Big Challenge for Me

Before starting this work, I had never written a single line of Swift in my entire development career.

I also had no native desktop application running in production.

My background was mainly in JavaScript. JavaScript was one of my first loves in programming. Over the years, I wrote production applications with React, worked with Vue around 2020 and 2021, used Node.js, and learned enough Electron to understand how desktop applications could be created with web technologies.

However, knowing how to create a basic Electron application and building a production-grade desktop application are two very different things.

TimoDesk was my first serious desktop product.

During the rewrite, I had to learn new technologies, understand operating-system-specific behavior, handle background services, manage performance, and make sure the applications could work reliably for real users.

I built both native applications myself while working under constant pressure and learning completely new technology stacks at the same time.

Seeing both applications reach production is a major personal achievement for me.

What TimoDesk Does

TimoDesk is a complete time tracking and productivity platform for remote teams, companies, agencies, and professionals.

The desktop application runs in the background and can:

Track working time
Record applications used during work
Track visited URLs
Capture screenshots at configured intervals
Synchronize time tracking data with the backend dashboard
Associate tracked time with projects and tasks
Operate silently without interrupting the user

For organizers, team managers, and company owners, TimoDesk also provides real-time visibility into team activity.

Managers can view:

Which team members are currently active
Who is idle or inactive
Which task each person is working on
Current project activity
Logged time and productivity information
Periodic screenshots and application usage

We also provide browser extensions for Chrome and Mozilla Firefox. These extensions help connect browser activity with the broader TimoDesk productivity system.

Why We Moved Away from Electron

Electron helped us build the original version quickly because it allowed us to use JavaScript and React.

For many applications, Electron is still a practical choice. However, TimoDesk has requirements that make native development especially valuable.

A time tracking application may remain active for an entire working day. It continuously handles timers, background synchronization, application monitoring, URL tracking, screenshots, and local system events.

Over long working sessions, every unnecessary resource matters.

The Electron version performed well in many situations, but we also experienced challenges such as:

Higher memory consumption
Larger installation packages
Resource pressure during long sessions
Less direct operating system integration
An interface that did not always feel completely native

The native rewrite gives us greater control over performance, background processing, memory usage, system permissions, and operating system integration.

The goal is to make TimoDesk lightweight, reliable, efficient, and closely connected to the operating system.

Building the macOS Version with Swift

The macOS version was developed using Swift.

This was one of the most challenging parts of the project because Swift was completely new to me.

I had to learn how macOS handles permissions, application monitoring, screenshots, background tasks, local storage, synchronization, system events, and user interface behavior.

macOS has strict privacy and security requirements, especially for applications that interact with screen recording, accessibility features, and application activity.

Building these features properly required more than simply translating JavaScript code into Swift. I had to redesign many parts of the application around the macOS environment.

The result is a native application that feels more closely integrated with macOS and gives us a stronger foundation for future development.

Building the Windows Version with .NET WPF

For Windows, I rebuilt TimoDesk using .NET and WPF.

The Windows application needed to handle many of the same responsibilities as the macOS application, but Windows has its own APIs, lifecycle behavior, installation requirements, background processes, permissions, and system-level challenges.

The WPF version gives us greater access to the Windows environment and allows us to optimize the experience specifically for Windows users.

Instead of maintaining one general desktop application for every operating system, we can now improve each version based on the strengths and behavior of its platform.

Linux May Be Next

I am also considering building a native Linux version.

The long-term goal is to make TimoDesk highly efficient across all major operating systems.

Linux presents its own challenges because desktop environments, display systems, permissions, and application packaging can vary significantly.

However, a native Linux version would allow TimoDesk to serve more developers, technical teams, remote companies, and organizations that rely heavily on Linux workstations.

TimoDesk Is Becoming More Than a Time Tracker

Time tracking is only one part of the larger vision.

We are building TimoDesk as a complete work operating system for remote teams.

Our team is actively working on:

Project management
Task management
Payroll management
Remote team operations
Productivity analytics
Mobile applications
AI-powered recommendations
Cost and performance insights

The objective is simple: teams should not need to move between many disconnected platforms to manage their daily work.

A company should be able to manage projects, assign tasks, track time, monitor productivity, calculate payroll, review team performance, and communicate important work information from one connected system.

Mobile Applications Are Also Coming

We are also developing mobile applications for TimoDesk.

The mobile application will make it easier for users and managers to stay connected to their work from anywhere.

Managers will be able to review team activity, tracked hours, projects, tasks, notifications, and productivity information without always opening the web dashboard.

The mobile experience is an important part of making TimoDesk a complete work solution.

AI Features for Better Productivity

We are also working on AI-powered features.

The purpose of these features is not simply to add AI because it is popular. The goal is to use existing work data to generate useful recommendations.

Based on how teams already use TimoDesk, the platform may be able to suggest:

Better task allocation
More accurate project estimates
Productivity improvements
Potential workflow problems
Time-consuming activities
Opportunities to reduce project costs
Work patterns that may affect delivery
Better planning for future projects

The idea is to help teams make better decisions using the work information they already generate.

What I Learned

This project reminded me that developers should not be limited by the technologies they already know.

A month ago, Swift was completely unfamiliar to me.

Today, I have a native macOS application written in Swift and a Windows application written in .NET WPF running in production.

The process was difficult. There were bugs, pressure, unfamiliar APIs, operating system restrictions, and many moments where the next step was not obvious.

But production software is often built that way.

You learn, solve one problem at a time, test constantly, and continue until the product becomes real.

This experience gave me more confidence in my ability to move beyond web development and build deeper, system-level software.

Try TimoDesk

TimoDesk is built for remote teams, agencies, companies, and professionals who need better visibility into projects, time, and productivity.

You can use it to:

Track project time
Monitor productivity
Review application and URL usage
Capture periodic screenshots
Manage remote team activity
Understand how working hours are spent

You can explore TimoDesk at:

https://timodesk.com

This native rewrite is only the beginning. The next stage is to make TimoDesk faster, smarter, more efficient, and capable of becoming the complete work platform remote teams can rely on every day.

Here is the clean Markdown version, ready for DEV.to, GitHub, Medium, or any Markdown editor:

From Electron to Native Desktop Apps: How I Rebuilt TimoDesk for macOS and Windows
Over the last month, I have spent most of my time rebuilding TimoDesk.

This was not a normal update or a small feature release. TimoDesk needed a complete desktop application rewrite.

Because TimoDesk is designed to run silently in the background for many hours, efficiency matters.

So I made a major decision.

I rebuilt the macOS application using Swift and the Windows application using .NET WPF.

Both applications are now in production.

Why This Was a Big Challenge for Me
Before starting this work, I had never written a single line of Swift in my entire development career.

I also had no native desktop application running in production.

However, knowing how to create a basic Electron application and building a production-grade desktop application are two very different things.

TimoDesk was my first serious desktop product.

I built both native applications myself while working under constant pressure and learning completely new technology stacks at the same time.

Seeing both applications reach production is a major personal achievement for me.

What TimoDesk Does
TimoDesk is a complete time tracking and productivity platform for remote teams, companies, agencies, and professionals.

The desktop application runs in the background and can:

Track working time

Record applications used during work

Track visited URLs

Capture screenshots at configured intervals

Synchronize time-tracking data with the backend dashboard

Associate tracked time with projects and tasks

Operate silently without interrupting the user

For organizers, team managers, and company owners, TimoDesk also provides real-time visibility into team activity.

Managers can view:

Which team members are currently active

Who is idle or inactive

Which task each person is working on

Current project activity

Logged time and productivity information

Periodic screenshots and application usage

We also provide browser extensions for Chrome and Mozilla Firefox. These extensions help connect browser activity with the broader TimoDesk productivity system.

Why We Moved Away from Electron
Electron helped us build the original version quickly because it allowed us to use JavaScript and React.

For many applications, Electron is still a practical choice. However, TimoDesk has requirements that make native development especially valuable.

A time-tracking application may remain active for an entire working day. It continuously handles timers, background synchronization, application monitoring, URL tracking, screenshots, and local system events.

Over long working sessions, every unnecessary resource matters.

The Electron version performed well in many situations, but we also experienced challenges such as:

Higher memory consumption

Larger installation packages

Resource pressure during long sessions

Less direct operating system integration

An interface that did not always feel completely native

The native rewrite gives us greater control over performance, background processing, memory usage, system permissions, and operating system integration.

The goal is to make TimoDesk lightweight, reliable, efficient, and closely connected to the operating system.

Building the macOS Version with Swift
The macOS version was developed using Swift.

This was one of the most challenging parts of the project because Swift was completely new to me.

I had to learn how macOS handles permissions, application monitoring, screenshots, background tasks, local storage, synchronization, system events, and user interface behavior.

macOS has strict privacy and security requirements, especially for applications that interact with screen recording, accessibility features, and application activity.

Building these features properly required more than simply translating JavaScript code into Swift. I had to redesign many parts of the application around the macOS environment.

The result is a native application that feels more closely integrated with macOS and gives us a stronger foundation for future development.

Building the Windows Version with .NET WPF
For Windows, I rebuilt TimoDesk using .NET and WPF.

The WPF version gives us greater access to the Windows environment and allows us to optimize the experience specifically for Windows users.

Instead of maintaining one general desktop application for every operating system, we can now improve each version based on the strengths and behavior of its platform.

Linux May Be Next
I am also considering building a native Linux version.

The long-term goal is to make TimoDesk highly efficient across all major operating systems.

Linux presents its own challenges because desktop environments, display systems, permissions, and application packaging can vary significantly.

However, a native Linux version would allow TimoDesk to serve more developers, technical teams, remote companies, and organizations that rely heavily on Linux workstations.

TimoDesk Is Becoming More Than a Time Tracker
Time tracking is only one part of the larger vision.

We are building TimoDesk as a complete work operating system for remote teams.

Our team is actively working on:

Project management

Task management

Payroll management

Remote team operations

Productivity analytics

Mobile applications

AI-powered recommendations

Cost and performance insights

The objective is simple: teams should not need to move between many disconnected platforms to manage their daily work.

Mobile Applications Are Also Coming
We are also developing mobile applications for TimoDesk.

The mobile application will make it easier for users and managers to stay connected to their work from anywhere.

Managers will be able to review team activity, tracked hours, projects, tasks, notifications, and productivity information without always opening the web dashboard.

The mobile experience is an important part of making TimoDesk a complete work solution.

AI Features for Better Productivity
We are also working on AI-powered features.

The purpose of these features is not simply to add AI because it is popular. The goal is to use existing work data to generate useful recommendations.

Based on how teams already use TimoDesk, the platform may be able to suggest:

Better task allocation

More accurate project estimates

Productivity improvements

Potential workflow problems

Time-consuming activities

Opportunities to reduce project costs

Work patterns that may affect delivery

Better planning for future projects

The idea is to help teams make better decisions using the work information they already generate.

What I Learned
This project reminded me that developers should not be limited by the technologies they already know.

A month ago, Swift was completely unfamiliar to me.

Today, I have a native macOS application written in Swift and a Windows application written in .NET WPF running in production.

The process was difficult. There were bugs, pressure, unfamiliar APIs, operating system restrictions, and many moments when the next step was not obvious.

But production software is often built that way.

You learn, solve one problem at a time, test constantly, and continue until the product becomes real.

This experience gave me more confidence in my ability to move beyond web development and build deeper, system-level software.

Try TimoDesk
TimoDesk is built for remote teams, agencies, companies, and professionals who need better visibility into projects, time, and productivity.

You can use it to:

Track project time

Monitor productivity

Review application and URL usage

Capture periodic screenshots

Manage remote team activity

Understand how working hours are spent

You can explore TimoDesk at:

https://timodesk.com

This native rewrite is only the beginning. The next stage is to make TimoDesk faster, smarter, more efficient, and capable of becoming the complete work platform remote teams can rely on every day.

This version uses Markdown-compatible headings, lists, and a clickable link.

bro markdown in # or whatever

From Electron to Native Desktop Apps: How I Rebuilt TimoDesk for macOS and Windows

Over the last month, I have spent most of my time rebuilding TimoDesk.

This was not a normal update or a small feature release. TimoDesk needed a complete desktop application rewrite.

Because TimoDesk is designed to run silently in the background for many hours, efficiency matters.

So I made a major decision.

I rebuilt the macOS application using Swift and the Windows application using .NET WPF.

Both applications are now in production.

Why This Was a Big Challenge for Me

Before starting this work, I had never written a single line of Swift in my entire development career.

I also had no native desktop application running in production.

However, knowing how to create a basic Electron application and building a production-grade desktop application are two very different things.

TimoDesk was my first serious desktop product.

I built both native applications myself while working under constant pressure and learning completely new technology stacks at the same time.

Seeing both applications reach production is a major personal achievement for me.

What TimoDesk Does

TimoDesk is a complete time tracking and productivity platform for remote teams, companies, agencies, and professionals.

The desktop application runs in the background and can:

Track working time
Record applications used during work
Track visited URLs
Capture screenshots at configured intervals
Synchronize time-tracking data with the backend dashboard
Associate tracked time with projects and tasks
Operate silently without interrupting the user

For organizers, team managers, and company owners, TimoDesk also provides real-time visibility into team activity.

Managers can view:

Which team members are currently active
Who is idle or inactive
Which task each person is working on
Current project activity
Logged time and productivity information
Periodic screenshots and application usage

We also provide browser extensions for Chrome and Mozilla Firefox. These extensions help connect browser activity with the broader TimoDesk productivity system.

Why We Moved Away from Electron

Electron helped us build the original version quickly because it allowed us to use JavaScript and React.

For many applications, Electron is still a practical choice. However, TimoDesk has requirements that make native development especially valuable.

Over long working sessions, every unnecessary resource matters.

The Electron version performed well in many situations, but we also experienced challenges such as:

Higher memory consumption
Larger installation packages
Resource pressure during long sessions
Less direct operating system integration
An interface that did not always feel completely native

The native rewrite gives us greater control over performance, background processing, memory usage, system permissions, and operating system integration.

The goal is to make TimoDesk lightweight, reliable, efficient, and closely connected to the operating system.

Building the macOS Version with Swift

The macOS version was developed using Swift.

This was one of the most challenging parts of the project because Swift was completely new to me.

I had to learn how macOS handles permissions, application monitoring, screenshots, background tasks, local storage, synchronization, system events, and user interface behavior.

macOS has strict privacy and security requirements, especially for applications that interact with screen recording, accessibility features, and application activity.

Building these features properly required more than simply translating JavaScript code into Swift. I had to redesign many parts of the application around the macOS environment.

The result is a native application that feels more closely integrated with macOS and gives us a stronger foundation for future development.

Building the Windows Version with .NET WPF

For Windows, I rebuilt TimoDesk using .NET and WPF.

The WPF version gives us greater access to the Windows environment and allows us to optimize the experience specifically for Windows users.

Instead of maintaining one general desktop application for every operating system, we can now improve each version based on the strengths and behavior of its platform.

Linux May Be Next

I am also considering building a native Linux version.

The long-term goal is to make TimoDesk highly efficient across all major operating systems.

Linux presents its own challenges because desktop environments, display systems, permissions, and application packaging can vary significantly.

However, a native Linux version would allow TimoDesk to serve more developers, technical teams, remote companies, and organizations that rely heavily on Linux workstations.

TimoDesk Is Becoming More Than a Time Tracker

Time tracking is only one part of the larger vision.

We are building TimoDesk as a complete work operating system for remote teams.

Our team is actively working on:

Project management
Task management
Payroll management
Remote team operations
Productivity analytics
Mobile applications
AI-powered recommendations
Cost and performance insights

The objective is simple: teams should not need to move between many disconnected platforms to manage their daily work.

Mobile Applications Are Also Coming

We are also developing mobile applications for TimoDesk.

The mobile application will make it easier for users and managers to stay connected to their work from anywhere.

Managers will be able to review team activity, tracked hours, projects, tasks, notifications, and productivity information without always opening the web dashboard.

The mobile experience is an important part of making TimoDesk a complete work solution.

AI Features for Better Productivity

We are also working on AI-powered features.

The purpose of these features is not simply to add AI because it is popular. The goal is to use existing work data to generate useful recommendations.

Based on how teams already use TimoDesk, the platform may be able to suggest:

Better task allocation
More accurate project estimates
Productivity improvements
Potential workflow problems
Time-consuming activities
Opportunities to reduce project costs
Work patterns that may affect delivery
Better planning for future projects

The idea is to help teams make better decisions using the work information they already generate.

What I Learned

This project reminded me that developers should not be limited by the technologies they already know.

A month ago, Swift was completely unfamiliar to me.

Today, I have a native macOS application written in Swift and a Windows application written in .NET WPF running in production.

The process was difficult. There were bugs, pressure, unfamiliar APIs, operating system restrictions, and many moments when the next step was not obvious.

But production software is often built that way.

You learn, solve one problem at a time, test constantly, and continue until the product becomes real.

This experience gave me more confidence in my ability to move beyond web development and build deeper, system-level software.

Try TimoDesk

TimoDesk is built for remote teams, agencies, companies, and professionals who need better visibility into projects, time, and productivity.

You can use it to:

Track project time
Monitor productivity
Review application and URL usage
Capture periodic screenshots
Manage remote team activity
Understand how working hours are spent

You can explore TimoDesk at:

https://timodesk.com

This native rewrite is only the beginning. The next stage is to make TimoDesk faster, smarter, more efficient, and capable of becoming the complete work platform remote teams can rely on every day.

How to Run a Successful Software Business in 2026

Moniruzzaman Saikat — Fri, 10 Jul 2026 06:29:36 +0000

Executive summary

Assumption: this article is written for founders and senior product and technology leaders building a horizontal software business in 2026, typically B2B SaaS with some prosumer lessons where useful. No specific industry vertical is assumed.

The strategic reality of 2026 is not that “every company needs AI.” It is that every software company now operates in a market where AI is widely adopted, buyers can research products faster, and the winning firms are those that turn AI from a demo into a governed, repeatable workflow advantage. McKinsey’s late-2025 survey found that 88% of organizations report regular AI use in at least one business function, 62% are at least experimenting with AI agents, and yet only about one-third say they have begun scaling AI across the enterprise. In other words, AI is mainstream, but scaled value is still scarce. That is the opening for disciplined software companies. citeturn20view0turn0search6

The market is also moving from experimentation to budgeted spend. Menlo Ventures estimates enterprise generative AI spending rose from $11.5 billion in 2024 to $37 billion in 2025, with $19 billion going to the application layer alone. Gartner forecast worldwide AI spending at nearly $1.5 trillion in 2025 and $2.52 trillion in 2026. Stanford’s 2026 AI Index reports that global corporate AI investment more than doubled in 2025 and that generative AI reached roughly 53% population-level adoption within three years of mass-market launch. citeturn29view0turn0search12turn0search2turn19view0turn30view0

The practical implication is straightforward: do not compete on “having AI.” Compete on proprietary context, workflow embedding, distribution, trust, and economics. The strongest business models in 2026 combine one of four patterns: bundled AI to defend the core suite, premium AI add-ons for governed enterprise workflows, seat-plus-usage hybrids for variable-cost workloads, and freemium-to-premium upgrades where AI expands supply and engagement. Current company behavior from GitHub, ServiceNow, Zoom, Atlassian, and Duolingo shows all four patterns working when tied to clear customer outcomes. citeturn24view4turn24view9turn25view0turn24view0turn24view2turn24view5turn19view4turn26view0

Introduction

In 2026, software is being sold into an environment where “deep research” is no longer a specialist capability. Knowledge workers can ask AI systems to compare vendors, synthesize customer references, summarize filings, inspect documentation, and pressure-test claims in minutes. That compresses information asymmetry and makes surface-level feature differentiation easier to copy and easier to expose. At the same time, agents are spreading into enterprise applications: Gartner projected in 2025 that 40% of enterprise apps would feature task-specific AI agents by 2026, while McKinsey found that agent use is most commonly reported in IT and knowledge management. citeturn0search6turn20view0

That changes the definition of a successful software business. The winning company is not the one with the flashiest model. It is the one that owns a high-frequency job to be done, sits on the system of record or system of action for that workflow, makes trustworthy decisions with proprietary context, and monetizes value without letting inference cost outrun gross margin. If 2024 was the year of pilots and 2025 the year of broad adoption, 2026 is the year of operational discipline. citeturn20view0turn29view0turn19view0

Market trends from 2024 to 2026

Three signals matter most. First, adoption is broadening faster than enterprise value is compounding. McKinsey reported 78% of organizations using AI in at least one business function in its March 2025 survey, up from 72% in early 2024 and 55% a year earlier; by November 2025, that figure had climbed to 88%. Yet only 39% reported any enterprise-level EBIT impact, and McKinsey’s “AI high performers” represented only about 6% of respondents. That gap between usage and measurable company-level value is exactly where durable software businesses can win. citeturn19view5turn20view0

Second, budgets are moving decisively toward applications. Menlo estimates the application layer captured $19 billion of enterprise generative AI spending in 2025, more than half the total, and coding alone represented $4.0 billion of departmental AI spend. Menlo also found that enterprises now prefer buying to building: 76% of AI use cases were purchased in 2025, versus an almost even split in 2024. Founders should read that as a distribution and packaging opportunity, not proof that in-house AI teams do not matter. citeturn29view0

pie showData
    title 2025 Enterprise Generative AI Spend
    "Application layer" : 19
    "Other layers" : 18

Menlo’s estimate that the application layer accounted for $19 billion of $37 billion in enterprise generative AI spend is a strong signal that the most immediate software value is still being captured in products that sit closest to the user and the workflow, not in raw model infrastructure. citeturn29view0

Third, the agent era is raising the bar for product design and governance. McKinsey found 62% of organizations were at least experimenting with AI agents by late 2025, and Gartner projected that task-specific agents would spread rapidly into enterprise applications by 2026. At the same time, Stanford’s AI Index warns that investment and capabilities are accelerating faster than governance and measurement frameworks. That means “agentic” is not a moat by itself; the moat is safe orchestration, grounded context, and measurable business outcomes. citeturn20view0turn0search6turn19view0

Business models, pricing, and case studies

The most resilient 2026 business model is usually a hybrid monetization stack: a base software subscription, optional premium AI add-ons where governance or specialization matters, and measured usage for expensive or autonomous workflows. Pure seat-based pricing works best when AI is lightweight and broadly used. Pure consumption works best when the customer already understands unit economics. Most companies should avoid copying API-style pricing blindly and instead price around the customer’s scarce unit of value: a developer seat, a workflow, a resolved case, a converted lead, or a high-intent research task. This synthesis reflects what we see in GitHub, Zoom, ServiceNow, Atlassian, and Duolingo. citeturn24view4turn24view9turn24view2turn25view0turn24view5turn19view4

Model	Best fit	Advantage	Primary risk
Bundled AI in core plans	Collaboration and suite products	Drives adoption fast and defends the base product	Hidden inference costs if usage spikes
Seat + usage credits	Developer tools and power-user workflows	Aligns margin with higher-intensity workloads	Billing complexity can slow adoption
Premium AI add-on	Enterprise workflow products	Best for governance, ROI proofs, and upsell	Requires strong sales enablement
Freemium + premium AI tier	Prosumer and consumer education/productivity	Expands funnel and converts power users	High support and compute costs at scale
Outcome-based automation	Narrow, high-value workflows	Strongest ROI narrative	Harder contracting and measurement

This comparison synthesizes current market patterns visible in Zoom’s no-extra-cost AI bundling, GitHub’s seat-plus-credit plans and 2026 usage-based extension, ServiceNow’s premium AI ACV growth, Atlassian’s Rovo bundle-plus-standalone pricing, and Duolingo’s freemium-to-premium conversion strategy. citeturn24view2turn24view3turn24view4turn24view9turn25view0turn24view0turn24view5turn19view4

GitHub Copilot is the clearest lesson in category creation and monetization evolution. Microsoft said in May 2025 that 15 million developers were already using GitHub Copilot; GitHub later reported that Copilot code review usage had grown 10x and accounted for more than one in five code reviews on GitHub. GitHub’s organization plans are seat-based, but in 2026 the company extended usage-based billing for heavier workloads. Lesson: start with simple adoption pricing, then add consumption when agents materially increase variable cost and delivered value. citeturn24view7turn24view8turn24view4turn24view9

ServiceNow shows how to sell AI as governed enterprise workflow expansion rather than as a generic assistant. Its 2025 annual-report disclosures said Now Assist surpassed $600 million in ACV in 2025 and aimed to exceed $1 billion ACV in 2026; Q1 2026 results said customers spending more than $1 million in ACV on Now Assist grew more than 130% year over year. Lesson: premium AI monetizes best where the software already owns approvals, workflows, and compliance-sensitive operations. citeturn5search2turn24view0

Zoom demonstrates the strategic logic of bundling. Zoom repeatedly emphasized that AI Companion remains available at no additional cost for paid Zoom Workplace accounts, while also launching customization and bring-your-own-data paths. Lesson: if AI strengthens the core suite, protects retention, and creates a future add-on market, bundling can be smarter than immediate monetization. citeturn24view2turn24view3

Duolingo is a useful reminder that AI should expand supply, not just trim labor. The company reported 12.2 million paid subscribers and 52.7 million DAUs as of Q4 2025, and said AI let it publish 20,500 skills in Q1 2026 versus 7,100 per quarter in 2025 and 1,800 in 2024. Even while expanding higher-cost AI features, it reported Q2 2025 gross margin of 72.4%, with lower-than-expected AI costs helping margins. Lesson: the best AI businesses use automation to widen their content or service frontier while protecting monetization and margin. citeturn19view4turn26view0turn26view1turn30view1turn30view2

Atlassian shows why the context layer matters. By late 2025, Atlassian said Rovo had rolled out to every paying cloud customer at no extra cost, that AI usage had more than doubled across its customer base, and that a standalone Rovo offer was coming at $5 per user. Its FY26 investor forum materials also highlighted faster ARR growth among customers using Rovo, while its GA MCP server emphasized admin controls, auditability, and open connectivity to external AI clients. Lesson: in the deep-research era, the product that wins is the one with the best permissions-aware knowledge graph, not merely the best chat box. citeturn24view5turn12search0turn24view6

Product strategy and AI integration

A robust 2026 product strategy starts with a narrow wedge: one painful, frequent, expensive workflow where the product can prove a measurable before-and-after delta. The second design rule is architectural: separate the system of record, the retrieval and data layer, the orchestration layer, and the execution layer. For dynamic knowledge tasks, retrieval-augmented generation remains the default because it improves updateability and provenance; for action-taking systems, tool use matters because model quality alone is not enough. The original RAG paper explicitly frames explicit memory as a way to improve factuality and update knowledge, and Toolformer formalizes model use of external tools and APIs. citeturn16search16turn23view4

The technical stack most founders should assemble looks like this: a product event and application database; a permissions-aware retrieval index over first-party content; model routing across at least a small, fast model and a stronger reasoning model; prompt and workflow versioning; offline eval sets; online experimentation; audit logs; and policy controls for data handling and action execution. The warning from Google’s “Hidden Technical Debt in Machine Learning Systems” still applies: in ML systems, complexity compounds silently, which is why prompt chains, retrieval adapters, evaluation code, and fallback logic must be treated as first-class production assets. citeturn23view2turn16search3

Safety and explainability are not “governance extras”; they are product features. NIST’s AI RMF defines trustworthy AI in terms that include validity, safety, security, transparency, explainability, privacy enhancement, and fairness, and organizes execution around GOVERN, MAP, MEASURE, and MANAGE. For LLM applications specifically, OWASP’s current guidance highlights prompt injection, insecure output handling, data poisoning, denial of service, supply-chain issues, and sensitive-information disclosure as core design risks. A production product should therefore show sources when possible, constrain tool permissions, sandbox actions, support human approval for high-impact steps, and log what the model saw, inferred, and executed. citeturn23view0turn23view1

Evaluation also needs to be tougher in 2026 than “the demo looked good.” SWE-bench and SWE-bench Verified matter beyond coding because they illustrate the broader point: realistic AI evaluation requires messy, long-context, multi-step tasks and human-validated benchmarks, not just synthetic prompts. In practice, that means every software company should maintain a living eval suite for its own top workflows: grounding accuracy, task completion, latency, safety violations, action reversals, and user acceptance. citeturn23view5turn23view6

AI delivery checklist

Tie every AI feature to a single workflow KPI before launch.
Default to retrieval and tools before fine-tuning.
Ship citations, audit logs, and approval gates early.
Version prompts, policies, and eval sets like code.
Track gross-margin impact per account, not just global token spend.

Go-to-market, legal, organization, and operations

Go-to-market in 2026 should sell workflow economics, not abstractions. McKinsey’s data show that cost benefits are most often reported in software engineering, manufacturing, and IT, while revenue gains are most often reported in marketing and sales, strategy and finance, and product or service development. The same research shows that high performers redesign workflows and set growth or innovation objectives alongside efficiency. So the best sales motion is a short, instrumented value proof with baseline metrics, redesigned process steps, and a buyer-visible dashboard of time saved, quality improved, or revenue unlocked. citeturn20view0

On pricing, founders should think in layers. Bundle lightweight assistance that improves core retention. Sell governed or specialized AI as a premium add-on. Add usage pricing only where autonomous or high-volume workloads create real variable cost or outsized customer value. GitHub’s shift toward usage-based billing for heavier Copilot workloads is a good signal that agentic features eventually need economic separation, while Zoom and Atlassian show the complementary logic of broad AI bundling to accelerate adoption and defend the suite. citeturn24view9turn24view2turn24view5

Legally, privacy and AI compliance now have to be designed in from day one. If you process personal data, GDPR applies in the EU, and California’s CCPA gives consumers rights over personal information collected by businesses. The European Data Protection Board’s December 2024 opinion on AI models addressed anonymity, legitimate interest, and the consequences of unlawful personal-data processing in AI development and deployment. Separately, the EU AI Act entered into force on August 1, 2024; prohibited practices and AI literacy obligations started applying on February 2, 2025; GPAI obligations applied from August 2, 2025; and the Act became broadly applicable on August 2, 2026, with some embedded-product obligations deferred further. For GPAI providers, the Commission’s code of practice centers on transparency, copyright, and safety and security. citeturn15search13turn21view4turn21view3turn21view0turn21view1turn21view2

Intellectual property remains unsettled enough that you should operate conservatively. The U.S. Copyright Office’s Part 2 report says copyrightability of AI outputs turns on the nature and extent of human contribution and maintains the human-authorship baseline; its Part 3 training report describes ongoing debate and unresolved litigation over the use of copyrighted works in model training. The practical response is not paralysis. It is provenance logs, documented dataset rights, customer contract clarity, output review for high-risk content, and indemnity language you can actually stand behind. citeturn22view1turn22view2turn21view5turn21view6turn22view3

Organizationally, the best setup is usually a compact cross-functional pod per wedge: a GM or PM, design lead, engineering lead, applied AI engineer, data or ML engineer, platform engineer, and a part-time security/privacy partner, plus a solutions engineer for customer feedback loops. McKinsey reports that software engineers and data engineers are among the most in-demand AI-related roles, that half of AI-using organizations need more data scientists, and that workforce reskilling is increasing. Infrastructure-wise, keep cost discipline through model routing, caching, retrieval optimization, asynchronous work queues, batch jobs, and hard spend guardrails. Ethical risk management should be reviewed monthly at the product-operations level: not only bias and privacy, but also inaccuracy, explainability gaps, over-automation, and customer deception. citeturn19view5turn20view0turn23view0turn23view1

A 12–18 month tactical roadmap with milestones and KPIs

The roadmap below assumes a company with an existing core product and a modest product-engineering base. The aim is not to launch ten AI features. It is to create one durable wedge, prove economics, then scale safely.

gantt
    title 12–18 Month Roadmap
    dateFormat  YYYY-MM-DD
    axisFormat  %b %Y

    section Foundation
    Select wedge workflow and baseline metrics      :a1, 2026-08-01, 45d
    Data contracts, permissions, logging, eval set  :a2, after a1, 45d

    section First product
    Build RAG + tool orchestration MVP             :b1, 2026-11-01, 60d
    Pilot with design partners                      :b2, 2027-01-01, 60d

    section Commercialization
    Launch paid beta and sales playbook             :c1, 2027-03-01, 60d
    Add premium governance/admin features           :c2, after c1, 60d

    section Scaling
    Model routing, caching, cost controls           :d1, 2027-05-01, 60d
    Expand to second workflow and partner channel   :d2, 2027-07-01, 90d

Milestones and KPIs

In the first 90 days, define the wedge and instrument it. The only acceptable launch criteria are a clear benchmark and a clear denominator: time to complete task, resolution rate, acceptance rate, conversion rate, or expansion signal. By month six, the pilot should show both user value and economic viability. By month twelve, the product should have a repeatable sales narrative and a cost envelope. By month eighteen, the company should be able to scale a second workflow without rewriting the platform. This sequencing mirrors what the strongest AI performers do: redesign workflows, scale selectively, and invest behind use cases that already show measurable value. citeturn20view0turn29view0

A practical KPI stack for 2026 is: activation-to-first-value in under one day for self-serve or under 30 days for enterprise; weekly active teams; net revenue retention; pilot-to-production conversion; model-grounded answer rate; citation coverage on knowledge tasks; human acceptance rate of generated outputs; auto-resolution rate for target workflows; p95 latency; inference cost per active account; gross margin by plan; security or policy incidents; and percentage of workflows with auditable logs. For enterprise AI, a board-level metric that matters more than raw MAUs is revenue or cost impact per redesigned workflow. citeturn20view0turn23view0

Founder checklist for the next quarter

Pick one workflow where the product can own both context and action.
Choose a pricing model that maps to customer value, not vendor token pricing.
Stand up evals, observability, and privacy reviews before general availability.
Require every AI feature to show one adoption KPI and one margin KPI.
Treat legal clarity and user trust as growth levers, not overhead.

A short conclusion: the successful software business of 2026 is not an “AI wrapper,” nor a traditional SaaS product with a chatbot bolted onto it. It is a software company that uses AI to turn proprietary context into better decisions, better workflows, and better economics than competitors can match. In a deep-research market, the firms that win will be the ones that are easiest to trust, easiest to prove, and hardest to replace.

The Future of Software Development: What Developers Should Expect

Moniruzzaman Saikat — Tue, 23 Jun 2026 18:52:27 +0000

Software development is changing faster than ever.

Over the past decade, we have seen the rise of cloud computing, mobile applications, DevOps, containers, and artificial intelligence. Technologies that once felt revolutionary have become standard tools in a developer's workflow.

As we look toward the future, one question continues to emerge:

Will developers still be needed?

The short answer is yes.

However, the role of developers is evolving. The future will not belong to developers who simply write code. It will belong to developers who can solve problems, understand business requirements, leverage AI effectively, and continuously adapt to new technologies.

Let's explore what the future of software development may look like from a developer's perspective.

AI Will Become a Standard Development Tool

Artificial intelligence is already transforming how developers work.

Tools such as AI coding assistants can generate boilerplate code, explain complex functions, write tests, and even suggest bug fixes.

Many developers fear AI will replace programmers.

In reality, AI is more likely to replace repetitive tasks than developers themselves.

Future developers will spend less time writing basic code and more time focusing on:

System design
Business logic
Architecture decisions
Security considerations
User experience
Problem solving

Learning how to collaborate with AI may become as important as learning a programming language.

Coding Will Become More Accessible

Historically, software development required deep technical knowledge.

Today, low-code and no-code platforms allow non-technical users to build simple applications.

This trend will continue.

Businesses will increasingly use visual development tools for straightforward applications and workflows.

However, complex systems will still require experienced developers.

Enterprise software, financial systems, healthcare platforms, and large-scale SaaS applications cannot rely entirely on drag-and-drop tools.

Developers will continue to play a critical role where complexity exists.

The Demand for Problem Solvers Will Increase

Companies do not hire developers because they need code.

They hire developers because they need solutions.

As AI becomes better at generating code, technical implementation becomes less of a competitive advantage.

Understanding the problem becomes more valuable than writing the solution.

Future developers who can bridge the gap between technology and business will stand out.

This means developing skills such as:

Communication
Critical thinking
Product understanding
Requirements analysis
Leadership

The ability to solve real-world problems will become a major differentiator.

Full Stack Skills Will Become More Valuable

The boundaries between frontend, backend, infrastructure, and operations are becoming increasingly blurred.

Modern developers often work with:

Frontend frameworks
APIs
Databases
Cloud services
CI/CD pipelines
Monitoring tools

While specialization will remain important, developers who understand the entire software lifecycle will have significant advantages.

The future favors developers who can see the bigger picture.

Security Will Become Everyone's Responsibility

Cybersecurity threats continue to grow every year.

In the past, security was often handled by dedicated teams.

Today, secure development practices are becoming part of every developer's responsibilities.

Future developers will need a stronger understanding of:

Authentication
Authorization
Data protection
Secure coding practices
Vulnerability management
Compliance requirements

Security awareness will no longer be optional.

It will be a core development skill.

Remote Development Is Here to Stay

The global software industry has proven that remote teams can build world-class products.

This has created opportunities for developers worldwide.

A talented developer in Bangladesh, India, Nigeria, or Brazil can now compete for opportunities that were once limited to specific geographic regions.

The future workforce will be increasingly global.

Developers who can communicate effectively, collaborate asynchronously, and work independently will thrive.

Continuous Learning Will Be Mandatory

One constant in software development is change.

Programming languages evolve.

Frameworks change.

New tools emerge.

Entire technology stacks can become obsolete within a few years.

The most successful developers will not be those who know a particular framework.

They will be those who know how to learn quickly.

Adaptability will become one of the most valuable skills in the industry.

Developer Productivity Will Increase Dramatically

Modern tools are already helping developers accomplish more with less effort.

In the future, developers may build applications in days that previously required weeks or months.

AI-assisted development, automation, cloud services, and mature frameworks will continue to accelerate software delivery.

This does not mean developers will work less.

Instead, expectations will increase.

Businesses will expect faster development cycles, quicker releases, and higher quality products.

Developers who leverage modern tools effectively will have a major advantage.

What Skills Should Developers Focus on Today?

If you want to prepare for the future, focus on skills that remain valuable regardless of technological changes.

These include:

Problem solving
Software architecture
System design
Communication
Security fundamentals
Cloud computing
AI-assisted development
Database design
Business understanding

Technologies may change.

Fundamental skills remain valuable.

Final Thoughts

The future of software development is exciting, not threatening.

AI will change how we write software.

Automation will eliminate repetitive work.

New tools will make development faster than ever before.

But technology alone does not create successful software.

People do.

Developers who embrace change, continuously learn, and focus on solving meaningful problems will remain in demand for years to come.

The future does not belong to the developers who write the most code.

It belongs to the developers who create the most value.

How to Use AI to Achieve 10x Productivity

Moniruzzaman Saikat — Tue, 23 Jun 2026 18:47:47 +0000

A few years ago, being productive meant working longer hours.

Today, it means working smarter.

Artificial Intelligence has become one of the biggest productivity multipliers available to developers, entrepreneurs, designers, marketers, and business owners. The people getting the most value from AI are not using it to replace their work. They are using it to eliminate repetitive tasks, speed up decision making, and focus on high value activities.

In this article, I will share how I use AI to dramatically increase productivity and how you can do the same.

Stop Thinking of AI as a Chatbot

Most people open ChatGPT, ask a random question, get an answer, and close the tab.

That is not where the real productivity gains come from.

Think of AI as a digital assistant that can help with:

Research
Writing
Coding
Planning
Documentation
Customer support
Content creation
Data analysis
Brainstorming

The goal is not to ask better questions occasionally.

The goal is to build workflows where AI becomes part of your daily process.

1. Use AI for Research

Research can consume hours.

Instead of opening twenty browser tabs, start with AI.

For example, instead of searching:

What is Laravel queue processing?

Ask:

Explain Laravel queues like I am a junior developer. Include practical examples and common mistakes.

You get a structured overview within seconds.

This does not replace verification, but it drastically reduces the time needed to understand a topic.

2. Turn AI Into Your Personal Writing Assistant

Writing documentation, emails, proposals, blog posts, and social media content takes time.

AI can generate first drafts almost instantly.

Some examples:

Blog outlines
Product descriptions
Documentation
Client emails
Meeting summaries

The biggest productivity boost comes from eliminating the blank page problem.

Instead of starting from zero, start with a draft and improve it.

3. Use AI for Coding

This is where many developers experience massive productivity gains.

AI can help:

Generate boilerplate code
Explain unfamiliar code
Debug issues
Create database schemas
Write test cases
Generate documentation

For example, instead of spending thirty minutes creating a CRUD structure, you can generate the foundation in minutes and focus on business logic.

The key is understanding the code before using it.

AI should accelerate development, not replace engineering judgment.

4. Automate Repetitive Tasks

Every repetitive task is a candidate for AI assistance.

Examples include:

Formatting data
Creating reports
Summarizing meetings
Generating content variations
Writing support responses

If you perform the same task more than three times per week, ask yourself:

Can AI help me do this faster?

The answer is often yes.

5. Use AI as a Thinking Partner

One underrated use of AI is brainstorming.

Whenever I am stuck on a problem, I ask AI to challenge my assumptions.

For example:

Give me five alternative solutions to this business problem.

Or:

What risks am I missing in this project?

This often reveals ideas I would not have considered on my own.

6. Build Prompt Templates

Many people waste time rewriting the same prompts.

Create reusable templates.

Blog Post Prompt

Act as a technical writer.

Write a detailed blog post about [TOPIC].

Target audience: [AUDIENCE]

Include:
- Introduction
- Practical examples
- Common mistakes
- Conclusion

Once you have a library of prompts, your productivity increases significantly.

7. Focus on Output, Not Activity

AI changes how we measure productivity.

Being busy is not the goal.

Producing results is.

If AI helps you complete a task in 10 minutes instead of 1 hour, that is not cheating.

That is efficiency.

The most productive professionals are not necessarily the hardest workers.

They are often the best at leveraging tools.

Common Mistakes

Blindly Trusting AI

Always verify important information.

AI can make mistakes.

Using Vague Prompts

Poor prompts lead to poor outputs.

Provide context, goals, and constraints.

Trying to Automate Everything

Not every task should be delegated.

Focus on repetitive and low value work first.

Final Thoughts

AI is not a magic button.

It will not automatically make you productive.

The real advantage comes from integrating AI into your daily workflow and using it consistently.

Start small.

Choose one repetitive task you do every day.

Use AI to reduce the time required for that task.

Then repeat the process.

Over time, the small improvements compound.

That is where the real 10x productivity gains come from.

[Boost]

Moniruzzaman Saikat — Mon, 29 Sep 2025 03:58:20 +0000