DEV Community: Ehsan Abedi

Building a Car Rental Booking Site: Availability Is the Hard Part

Ehsan Abedi — Wed, 28 Oct 2026 17:47:16 +0000

A car rental website looks simple from the outside: pick dates, pick a car, pay. Under the hood, almost every problem comes back to one question: is this car actually free for these dates? Get that wrong and you get double bookings, angry customers at the airport and a team that stops trusting the website.

I'm a freelance WordPress and Flutter developer in Famagusta, North Cyprus, where a lot of small rental companies still take bookings over WhatsApp. Here is how I approach a booking site for them, from a developer's point of view.

Model the fleet, not just "products"

The tempting shortcut is to treat each car as a WooCommerce product with stock. It breaks quickly, because rental stock is about time, not quantity. I usually model it like this:

Car group (e.g. "Economy automatic"): what the customer books, with photos, seats, luggage and transmission.
Vehicle: the physical car with its plate, linked to a group, which can be blocked for service.
Booking: vehicle, pick-up datetime, return datetime, locations, extras, status.

Customers book a group and the system assigns a free vehicle. That way one car in the workshop doesn't make the whole group "sold out" on the website.

The overlap query

Two bookings clash when one starts before the other ends and ends after the other starts. In SQL that is the classic interval check:

SELECT COUNT(*) FROM wp_rental_bookings
WHERE vehicle_id = %d
  AND status IN ('confirmed', 'pending')
  AND pickup_at < %s   -- requested return
  AND return_at > %s;  -- requested pick-up

Small details that matter:

Store datetimes in UTC and convert for display. Rental days cross midnight, and daylight saving changes will bite you otherwise.
Add a buffer after each return (cleaning, fuel, delivery time) before the car is free again.
Count pending bookings too, so two people paying at the same time can't both get the last car.

Prevent the race condition

Checking availability and inserting the booking are two steps. If two requests run between them, both pass the check. Wrap the check and the insert in a transaction and lock the vehicle row (SELECT ... FOR UPDATE on InnoDB), or hold a short reservation that expires if payment isn't completed in, say, 15 minutes. It's boring code, and it's the code that saves the business.

Prices are rules, not numbers

Rental pricing is rarely "price × days". There are seasonal rates, discounts for longer rentals, a minimum number of days, one-way fees and extras like a child seat or full insurance. I keep these as small, testable rules and calculate the total on the server, never only in JavaScript. The customer sees the full breakdown before confirming, which also reduces the "why is it more at the desk?" conversations.

Airport delivery and the booking form

Many visitors here land at Ercan Airport or arrive at the port in Kyrenia. Delivery locations, a delivery fee and a flight number field belong in the booking form itself. A booking that arrives with all the details means one message for the staff instead of five.

Speed and languages

Most people book on a phone, often on roaming data, so the search results page has to be light: real image sizes, WebP, lazy-loading below the fold, and no heavy slider. On a four-language WordPress site I improved homepage PageSpeed from 51 to 75 on mobile and 81 to 97 on desktop without touching the design, mostly through this kind of asset discipline. For languages I use WPML with real URLs per language and hreflang, so the German page can rank for German searches.

Where a Flutter app fits

The website is for customers. The part rental companies love is a small staff app: at pick-up and return the employee takes photos of the car, records fuel and mileage, and the customer signs on the screen. Built in Flutter, it runs on Android and iPhone and talks to the same WordPress database through the REST API, so bookings and check-ins stay in one place.

I wrote a client-facing version of this, for rental company owners rather than developers, here: Car Rental Website Design in North Cyprus.

How do you handle availability in booking systems: database locks, short reservations, or something else?

Building a Restaurant Website? Please Don't Ship the Menu as a PDF

Ehsan Abedi — Tue, 27 Oct 2026 19:07:30 +0000

Ask anyone how they choose a new restaurant or café and the answer is almost always the same three steps on a phone: look at the food, check the menu, find out how to get there. A restaurant website has one job, and that's making those three steps fast.

I'm a freelance WordPress and Flutter developer in Famagusta, North Cyprus. Small local businesses are a big part of what I think about, and restaurant sites are where the same few technical decisions matter most. Here is how I'd build one, from a developer's point of view.

The menu is a web page, not a file

The most common mistake is uploading the menu as a PDF or a photo of the printed card. On a phone, a PDF has to be downloaded, pinch-zoomed and scrolled sideways. Search engines also get very little from it, so a search like "breakfast in Famagusta" has nothing to match.

In WordPress I build the menu as real content: a custom post type or a simple repeater with sections, dish names, short descriptions and dietary tags (vegan, gluten-free, spicy). Then:

The owner edits a dish from the dashboard in a minute, without asking a developer.
The page is plain HTML, readable on any screen and fully indexable.
If they still want a printable version, a "Download PDF" link sits under the web menu, not instead of it.

Tell search engines it's a restaurant

Local search is where restaurants live: "restaurant near me", "best coffee in Famagusta". Structured data helps Google connect the website with the place. A minimal Restaurant block looks like this:

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Example Café",
  "servesCuisine": ["Mediterranean", "Breakfast"],
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Famagusta",
    "addressCountry": "CY"
  },
  "telephone": "+90 000 000 0000",
  "openingHours": ["Mo-Sa 08:00-22:00"],
  "hasMenu": "https://example.com/menu/",
  "acceptsReservations": "True"
}

Then the part developers often skip: the name, address, phone number and opening hours must be exactly the same on the website, the Google Business Profile and the social pages. Mismatched data makes Google trust all of it less, and it sends guests to a closed door.

Photos sell, and photos make it slow

Food photos do more selling than any copy, and they're also the number one reason restaurant sites are slow. My routine:

Resize to the size actually displayed, compress, serve WebP with srcset.
loading="lazy" on everything below the fold, but not on the hero image, because lazy-loading the largest image hurts LCP.
Set width and height so the layout doesn't jump while photos load.

On a four-language real estate site I work on, a colleague and I raised the median mobile PageSpeed score from 51 to 75 and desktop from 81 to 97 without changing the design. Most of that came from exactly this kind of image and asset discipline.

One obvious next step

Every page should make the next action a single tap:

tel: link for calling,
a https://wa.me/ link with a pre-filled message, which in North Cyprus is often how people actually book,
a short reservation form, or a link to the delivery platform the place already uses.

Online ordering with WooCommerce is possible, but I usually start with the simple version and add ordering only when the owner really needs it.

Languages: real pages, not a translate button

A restaurant in North Cyprus serves locals, visitors from Turkey, tourists from Europe and the UK, and a lot of international students. With WPML, each language gets its own URLs and hreflang tags, so Google can show the Turkish menu to Turkish searches. An automatic "translate" widget doesn't do that.

What I leave out

Autoplay music, a long intro video, a newsletter pop-up in the first second, a slider with eight slides. Each one makes the site slower and pushes the menu further down. A small, fast site with a clear menu wins.

When an app makes sense

Once a place has regular customers, a Flutter app can do what a website can't: a loyalty card on the phone, push notifications for a weekend event, fast reordering. The nice part is that the app can read the menu from the same WordPress site through the REST API, so the owner updates one place and both stay in sync. For most restaurants, though, the website and the Google profile come first.

I wrote a longer, client-facing version of this for restaurant and café owners here: Restaurant & Café Website Design in North Cyprus.

What's the worst restaurant-website pattern you keep running into?

The Monthly WordPress Maintenance Checklist I Use for Small Business Sites

Ehsan Abedi — Fri, 23 Oct 2026 14:13:28 +0000

Most WordPress sites don't break in one dramatic moment. They decay quietly: a plugin stops getting updates, the cache stops working after an update, someone uploads a 6 MB photo, the contact form silently stops sending email. Nobody notices until a customer says "I sent you a message last week".

I'm a freelance WordPress and Flutter developer in Famagusta, North Cyprus, and besides building sites I look after existing ones. This is the routine I actually use. It's boring on purpose: boring maintenance is what keeps sites from becoming emergencies.

Before touching anything: a backup you can restore

Full backup of files and database, stored outside the site's public folder.
On some shared hosts wp db export fails because proc_open is disabled. mysqldump with the credentials from wp config get works instead.
Once in a while, actually restore a backup to a staging copy. A backup you've never restored is a hope, not a backup.

Updates, one group at a time

Core, theme and plugins, but not all blindly at once on a site that matters. Update, then check, then continue.
After updating, check the pages that make money: home, the main service page, the contact form, checkout if there is one.
Watch for side effects of cache plugins. On one site, a plugin action triggered a full cache purge, and the optimised CSS files briefly returned 404s, so the site loaded unstyled until the cache was rebuilt. Now I check that every CSS and JS file on key pages returns 200 after any update.

Security basics that catch most problems

Hidden login URL, two-factor authentication for every admin, limited login attempts.
No public readme.html, no xmlrpc.php if nothing uses it, no user enumeration through ?author=1 or /wp-json/wp/v2/users.
Remove the WordPress version from the page source, including the ?ver= on core assets. It doesn't make the site invisible, but it stops making it easy for bots to match the site to a known vulnerable version.
Review admin users and installed plugins. Every plugin is code you're trusting.

Speed that doesn't slide back

Run PageSpeed on the home page and one inner page, and take the median of several runs, because single runs vary a lot.
Look for new full-size images, new third-party scripts and cache misses.
On a four-language real estate site I work on, a colleague and I raised the median mobile PageSpeed score from 51 to 75 and desktop from 81 to 97 without changing the design. Monthly checks are what keep those numbers from drifting down.

Forms, links and search visibility

Send a real test message through every form and confirm it arrives. Email deliverability breaks more often than people think.
Check Google Search Console for new indexing problems, 404s and manual actions.
Make sure the sitemap still lists the right pages and nothing important is accidentally noindex.

Content: the part clients forget

Maintenance isn't only technical. Old prices, last year's opening hours and a "new" offer from two seasons ago hurt trust as much as a slow page. A short monthly content check with the client is often the most valuable part of the routine.

When the client also has an app

When a Flutter app reads its content from the same WordPress site through the REST API, one routine covers both: if a WordPress update changes an endpoint or a field, it gets caught before users of the app notice.

I wrote the client-facing version of this, explaining what maintenance includes and when a business needs a monthly plan, here: WordPress Maintenance in North Cyprus.

What's on your maintenance checklist that isn't on mine?

Why I Still Recommend WordPress to Small Business Clients in 2026 (and When I Don't)

Ehsan Abedi — Fri, 23 Oct 2026 11:38:22 +0000

Every few months someone tells me WordPress is dead. Then a hotel, a clinic or a property agency asks me for a website, and I recommend WordPress again.

I'm a freelance WordPress and Flutter developer in Famagusta, North Cyprus. My clients are mostly small businesses: they want a site that looks professional, loads fast, shows up on Google, and that they can update themselves without calling me for every price change. Here's my honest reasoning, including the cases where I suggest something else.

The client needs to own the content, not me

The most important question I ask is: who will update this site after launch?

For most small businesses the answer is "us". WordPress gives them a dashboard they understand in an afternoon. They change a price, add a photo or publish a news post, and the design stays consistent. That alone removes most of the "my developer disappeared" stories I hear from new clients.

Design freedom without hand-coding every page

With a page builder like Elementor, I can deliver a custom design and still hand over pages the client can edit. Everything is responsive by default, which matters when nearly all visitors arrive on a phone.

I don't treat the page builder as an excuse to skip structure, though. Clean headings, sensible templates and reusable sections make the site easier to maintain and better for SEO.

SEO is solid out of the box

WordPress outputs clean, crawlable HTML. Add an SEO plugin such as Rank Math and you control titles, descriptions, sitemaps and structured data per page. The platform won't rank a site on its own, but it never gets in the way of good content and internal linking.

Multilingual sites are where it really shines

Many of my clients serve customers in several languages. WordPress with WPML gives every language its own URLs, menus, forms and SEO settings, including right-to-left languages like Persian and Arabic.

I work on a four-language real estate site (English, German, Turkish and Persian) built exactly this way. Doing that with a hosted site builder would be painful; with WPML it's a normal day's work.

"But WordPress is slow"

It's slow when it's set up carelessly. With decent hosting, page caching, a CDN, properly sized images and some discipline about plugins, WordPress can score very well on PageSpeed.

On that real estate site, a colleague and I raised the median mobile PageSpeed score from 51 to 75 and desktop from 81 to 97 without changing the design. The work was mostly boring: caching rules, image sizes, removing what wasn't needed and testing every change.

It grows with the business

Forms, bookings, an online shop with WooCommerce, property listings with maps and search: there's a mature plugin for almost everything a small business asks for in year two. And because WordPress is open source, the client owns the site and can move hosts or developers whenever they want.

When I don't recommend WordPress

Being honest about this is part of the job:

A one-page site that will never change. A static site or a simple builder is cheaper to run.
A web application, not a website. Dashboards, complex user accounts and real-time features belong in a proper app framework.
A client who won't keep it updated. WordPress needs updates and backups. If nobody will do that, I either include maintenance or suggest a hosted platform.

WordPress and apps together

The part I enjoy most: when a client also wants a mobile app, I build it in Flutter and let it read pages, products or listings from WordPress through the REST API. The client updates content once in a dashboard they already know, and it appears on the website and in the app.

I wrote the client-facing version of this, with a short FAQ, here: Why WordPress Is Still the Best Choice for Business Websites. If you're a business looking for a site, you can see my web design services in North Cyprus.

Fellow developers: what's your rule for when not to use WordPress?

How I Explain Cross-Platform vs Native to Clients (and Why I Usually Recommend Flutter)

Ehsan Abedi — Wed, 21 Oct 2026 08:41:51 +0000

Almost every first call about a new app reaches the same question within ten minutes: "Should we build two native apps, or one app for both phones?"

I'm a freelance Flutter and WordPress developer in Famagusta, North Cyprus, and most of my clients are small and medium businesses, not tech companies. They don't need a lecture on rendering engines. They need a clear answer they can take back to their partner or their accountant. This is the explanation I've settled on, and the cases where I still say "go native".

The one-sentence version

A native app is built twice: once for Android (usually Kotlin) and once for iPhone (Swift). A cross-platform app is built once, with a framework like Flutter or React Native, and runs on both. Often on the web and desktop too.

Everything else follows from "built once" versus "built twice".

What "built once" means for a business

When I put it in business terms, the list is short:

Budget: one codebase, one development process, one round of testing. Not two.
Launch day: Android and iPhone users get the app on the same day, instead of one platform waiting for a second team.
Consistency: the brand, screens and features are identical whatever phone the customer has.
Maintenance: a bug is fixed once, a feature is built once, then released everywhere.
Growth: the same code can later become a web or desktop version.

Maintenance is the point that lands best. Clients think about the launch; I ask them to think about year two, when every change in a native setup has to be made, tested and released twice.

"But won't it feel slow?"

This is the worry clients bring from older hybrid apps that were basically websites in a wrapper. I explain that Flutter is different: it compiles to native ARM code and draws its own UI with its own rendering engine, so scrolling, animations and transitions are smooth. For the kind of apps most businesses need (bookings, ordering, listings, internal tools, content), users simply can't tell.

Then I show them something running on my own phone. A demo beats any argument.

When I still recommend native

Being honest about the limits is what makes the recommendation believable. I suggest a fully native approach when:

The app depends on brand-new platform features on the day they're released.
It's a demanding 3D game or something close to the metal.
The client already has strong native teams and an existing native codebase.

For most other cases, Flutter can still call native code through platform channels when one specific feature needs it, so you keep one main codebase and still have an escape hatch.

The comparison table I send after the call

	Two native apps	One cross-platform app
Codebases	Two	One
Budget	Higher	Lower
Launch on Android & iOS	Often at different times	Same day
Design consistency	Harder to keep identical	Identical by default
Maintenance	Every change done twice	Every change done once

It's deliberately simple. The client will forward it to someone, and it has to make sense without me in the room.

Questions clients ask next

"Is it harder to publish?" No. It goes to Google Play and the App Store as two normal apps, built from the same project.

"Can we add native parts later?" Yes, small native pieces can be added for very specific features.

"Will users notice?" With a well-built Flutter app, usually not.

The bonus: the website and the app together

Most of my clients also need a website, because customers find them on Google before they ever install an app. When the same developer builds the WordPress site and the Flutter app, the app can read listings, products or bookings from the site's REST API. Content is updated once and appears in both places.

I wrote the client-facing version of this guide, with a short FAQ, here: Cross-Platform vs Native Apps: Why Build Once for Android and iOS. If you're a business planning an app, you can see my Flutter app development services in North Cyprus.

Fellow developers: how do you explain this trade-off to non-technical clients? I'd love to steal a better analogy.

When I Tell a Client to Hire an Agency Instead of Me (a Freelance Flutter Developer's Honest Checklist)

Ehsan Abedi — Tue, 20 Oct 2026 09:41:29 +0000

Almost every business owner who wants an app asks the same question early on: should I hire a freelance developer or an agency? Most articles on this are written by one side trying to win the deal.

I'm a freelance Flutter and WordPress developer in Famagusta, North Cyprus. I'd rather lose a project at the first call than win one I shouldn't be doing alone. So here's the checklist I actually use, from the developer's side of the table. If you freelance too, I think being this open is one of the best ways to earn trust.

Projects where one developer is the right fit

With Flutter, a single codebase becomes a native app for Android and iPhone, which changes the maths for small and medium projects. These are well within reach of one experienced developer:

Booking apps for clinics, salons and gyms
Ordering apps for restaurants and cafés
Property apps for real estate agencies, reading listings from the company website
Internal tools for a team: schedules, checklists, simple dashboards
Content apps that mirror a WordPress site through the REST API

What the client gets: direct contact with the person writing the code, quick decisions, lower overheads and one person who knows the app inside out after launch.

Projects where I recommend an agency

I say this openly when one of these applies:

Several apps that must ship at the same time, for example a marketplace with separate apps for customers, drivers and partners, all on a tight deadline.
Many parallel workstreams: heavy custom backend, admin panel, three platforms and a web app, all at once.
The company needs a formal supplier with many staff, insurance and procurement paperwork.
24/7 operational support with guaranteed response times from day one.

None of this means a freelancer can't contribute. Often the honest answer is "start with an agency for version one, or let me build a focused first version and grow from there".

Questions I encourage clients to ask me (and any developer)

Can I see apps or app concepts you designed and built?
How will the app run on both Android and iPhone?
Which backend stores the data: Firebase, my website or something else?
Will I own the code repository and the App Store and Google Play accounts?
How do we test before release?
What happens after launch, when Android and iOS update?

The ownership question is the one that removes most of the "bus factor" risk of hiring one person. If the client owns the repo and the store accounts, and the code is clean and documented, any qualified Flutter developer can continue the work.

Cost: features matter more than who builds it

The price of an app depends far more on what it has to do than on who writes it: number of screens, logins, payments, languages, integrations. A freelancer usually has lower overheads; an agency includes the cost of a bigger team and more process. Both can be fair.

The website and the app from one person

This is the part I enjoy most. When the same developer builds the WordPress site and the Flutter app, the app can read listings, products or bookings straight from the site. The client updates content once and it appears everywhere. Two projects become one system.

Why this matters if you freelance

Telling a client "this one is too big for me alone" feels like losing work. In my experience it does the opposite: clients remember who was honest, and they come back for the projects that do fit.

I wrote a client-facing version of this guide, with a short FAQ, here: Freelance App Developer or Agency: Which Is Right for Your Business?. If you're a business looking for help, you can see my app development services in North Cyprus.

Freelancers: where do you draw the line between "I can do this" and "you need a team"?

The 10 Questions Clients Should Ask Before Hiring a Web Designer (and How I Answer Them as a WordPress Developer)

Ehsan Abedi — Mon, 19 Oct 2026 19:00:17 +0000

Most small business owners hire a web designer once every few years. They don't know which questions matter, so they compare quotes by price and by how nice the homepage mockup looks. Then, six months later, they find out the site is slow, they can't edit it, and nobody set up Search Console.

I'm a WordPress and Flutter developer in Famagusta, North Cyprus. When I talk to a new client, I try to answer the questions they should be asking, even if they don't ask them. Here are the ten I think matter most, written from the developer's side of the table. If you freelance or run a small studio, having a clear answer to each one is also a good way to stand out from cheaper quotes.

1. "Can I see live sites you built and still maintain?"

Screenshots in a portfolio prove very little. A live site proves you can ship, and a site you still maintain proves it held up.

How I answer: I send live links and suggest the client opens them on their own phone, on mobile data. If a site is slow or the contact button is hard to find, they'll notice in ten seconds, and that's fair.

2. "How will you learn about my business?"

If the first meeting is about colours and fonts, something is wrong. The first meeting should be about customers: who they are, what language they search in, and what you want them to do on the site (call, send a WhatsApp message, book, buy).

How I answer: I start with a short list of questions about customers and goals, and I only talk about design after that.

3. "Which platform will you use, and will I own everything?"

This is the question that protects the client most. Who owns the domain? Who has the hosting login? Can they move the site to another provider without you?

How I answer: I build on WordPress, the domain and hosting are registered in the client's name, and they get admin access from day one. If we ever stop working together, they can take the site anywhere.

4. "Will it be designed for phones first?"

Most visitors arrive on a phone, so the mobile layout should be planned first, not patched at the end.

How I answer: I show the mobile version during the design phase and ask the client to test it on their own device before launch, not only in a desktop browser with DevTools.

5. "How fast will it load?"

Speed affects both visitors and rankings, but it's rarely in the brief. A good developer brings it up without being asked: image sizes and formats, caching, render-blocking scripts, and Core Web Vitals.

How I answer: I explain what we'll measure and use real numbers from my own work. On a four-language real estate site I work on, a colleague and I raised the median mobile PageSpeed score from 51 to 75 and the desktop score from 81 to 97. I always say that the score is a median of several runs, because a single run varies a lot.

6. "What do you do for SEO?"

"SEO" in a quote can mean anything. Clients should ask what exactly is included on launch day.

How I answer: titles and meta descriptions per page, one H1 per page, clean headings, structured data (Person or Organization, Breadcrumbs, FAQ where it fits), an XML sitemap, robots.txt, and the site verified in Google Search Console with the sitemap submitted. That's the foundation. Rankings still depend on content, links and time, and I say that too.

7. "Can the site speak my customers' languages?"

In a place like North Cyprus, one small business can get messages in English, Turkish, German, Russian and Persian in the same week. Multilingual is normal here, not a luxury.

How I answer: each language gets its own URL and its own SEO, with proper hreflang tags. If the client needs Persian or Arabic, I make sure the right-to-left layout is designed and tested, not just mirrored. I use WPML for this on WordPress.

8. "Can I update it myself?"

If the client has to email you to change a price, both sides lose.

How I answer: at handover I run a short training session and leave a simple written guide for the most common edits: text, photos, prices, new blog posts.

9. "How does the project run, step by step?"

A clear process protects both the client and the developer.

How I answer: a written proposal with pages and features, a design the client approves before building starts, preview links during development, a launch checklist, and payments split into stages that follow those steps.

10. "What happens after launch?"

Websites need updates, backups and security fixes. Somebody has to own that.

How I answer: I say clearly who handles updates and backups, how fast I respond, and what ongoing care costs, before the project starts, not after the first plugin conflict.

Bonus: "Can you also build the app later?"

Many businesses start with a website and add a mobile app later for repeat customers. If the same developer can plan both, the app can read its content straight from the WordPress REST API, so there's one place to manage listings, menus or prices.

How I answer: that's exactly why I work with both WordPress and Flutter. The website and the app share content and design instead of becoming two separate projects.

Why this matters for developers

If you're competing with cheaper quotes, these answers are your advantage. Clients rarely know to ask about ownership, speed or Search Console, but once you explain them in plain language, the conversation stops being about price.

I wrote a client-facing version of this checklist, with a short FAQ, here: How to Choose a Web Designer: 10 Questions to Ask Before You Hire. If you're a business looking for help, you can see my web design services in North Cyprus.

What would you add to this list? I'm curious which question your clients ask most often.

One Set of Listings, Two Front Ends: Planning a Real Estate App with Flutter and the WordPress REST API

Ehsan Abedi — Sun, 18 Oct 2026 14:42:10 +0000

Most real estate agencies already have a WordPress website full of listings. When they ask for an app, the expensive mistake is building a second backend with its own database, its own admin panel and its own copy of every property. Six months later, the website and the app show different prices.

I'm a WordPress and Flutter developer in Famagusta, North Cyprus, and I work on a multilingual real estate website (English, German, Turkish, Persian). These are the notes I use when planning how an app should sit next to a site like that. The short version: keep WordPress as the single source of truth and let Flutter read from it.

1. Expose the listings through the REST API

If properties are a custom post type, make sure it's available in the REST API:

register_post_type( 'property', [
    'public'       => true,
    'show_in_rest' => true,           // exposes /wp-json/wp/v2/property
    'rest_base'    => 'property',
    'supports'     => [ 'title', 'editor', 'thumbnail', 'custom-fields' ],
] );

Fields like price, bedrooms and area usually live in post meta or ACF. Register only the fields the app actually needs (register_rest_field or register_post_meta with show_in_rest), so you don't leak internal data and responses stay small.

2. Keep the Flutter side boring and testable

A clean split makes the app easy to change later:

Data layer: a repository that calls /wp-json/wp/v2/property and maps JSON to a Property model
Domain layer: plain Dart entities and use cases (search, favourite, request a viewing)
Presentation: BLoC per screen (list, details, favourites)

class PropertyRepository {
  PropertyRepository(this._client, this._baseUrl);
  final http.Client _client;
  final String _baseUrl;

  Future<List<Property>> fetch({int page = 1, String lang = 'en'}) async {
    final uri = Uri.parse(
      '$_baseUrl/wp-json/wp/v2/property?page=$page&per_page=20&lang=$lang&_embed',
    );
    final res = await _client.get(uri);
    if (res.statusCode != 200) {
      throw Exception('Failed to load properties (${res.statusCode})');
    }
    final data = jsonDecode(res.body) as List;
    return data.map((e) => Property.fromJson(e as Map<String, dynamic>)).toList();
  }
}

_embed pulls in the featured image in the same request. Use pagination from day one: real agencies have hundreds of listings.

3. Multilingual and right-to-left from the start

International buyers expect their own language. Two things save a lot of pain later:

Content language comes from WordPress. With WPML, each translation is its own post, so the app requests the right language (the lang parameter above, or a language-specific endpoint depending on your setup).
UI language lives in Flutter's localisation files. For Persian and Arabic, Flutter flips the layout to right-to-left automatically when the locale changes. Still test every screen in RTL: icons with a direction, price formats and mixed English/Persian text are where bugs hide.

4. Features buyers actually use

For a first version, these are the features I would prioritise:

Search with filters (area, type, bedrooms, price, sea view, pool)
Map view with pins along the coast
Property pages with a gallery, key facts and a floor plan
Favourites and sharing a listing on WhatsApp
A one-tap viewing request and phone/WhatsApp buttons
Alerts when a new listing matches a saved search

Video tours, side-by-side comparison, buyer accounts and an agent area can come later, once people are using the app.

5. Notifications without a second database

Saved-search alerts sound like they need a big backend. A simple approach: store each saved search (filters plus the device token) in a small table or service, and run a scheduled job when a new property is published that checks for matches and sends a push notification. The listings themselves still live only in WordPress.

6. Performance on both sides

The app is only as fast as the API behind it. Cache REST responses on the server, return only the fields you need, and serve images as WebP in sensible sizes. On the website I work on, a colleague and I raised the median mobile PageSpeed score from 51 to 75, and most of that came from the same basics: caching, lighter images and fewer heavy scripts.

FAQ

Can the app use listings from an existing WordPress site?
In most cases, yes. Once the post type and fields are exposed in the REST API, the app reads the same data.

Do I still need the website if I have an app?
Yes. The website brings new buyers in from Google. The app keeps returning buyers close.

Android and iPhone?
One Flutter codebase covers both, which keeps development and maintenance lower than building two separate apps.

Originally published on ehsanabedi.com. You can see a real estate app concept in my portfolio.

8 Things a Hotel or Villa Website Needs Before Guests Will Book (A Developer's Checklist)

Ehsan Abedi — Sun, 18 Oct 2026 11:15:35 +0000

Most guests book their stay from a phone. They often scroll on mobile data, sometimes from an airport gate, and they make up their mind in a few seconds. A hospitality website gets judged by different rules than a portfolio or a company page: it either answers "what will I get, and how do I book it?" right away, or the visitor goes back to a booking platform.

I am a WordPress and Flutter developer in Famagusta, North Cyprus. Many of the small hotels, villas and holiday rentals around me depend on summer visitors from Turkey, the UK, Germany and Russia. Here is the checklist I use when I build or review a hospitality site. If you build sites for clients in tourism, most of it applies wherever you are.

1. Photos that sell the stay, without killing speed

People decide to book by looking. Large, bright photos of the rooms, the pool and the view do more than any paragraph. The technical part is keeping them fast:

serve WebP at the size each breakpoint actually needs
lazy-load everything below the first screen
use a gallery that swipes properly on touch screens
put the most convincing photo first, not the reception desk

2. One page per room or villa

Each unit needs its own URL with the essentials visible at a glance: number of guests, beds, bathrooms, distance to the beach, what is included and the price per night or per season. If you can, add an availability calendar. If you can't, a clear "Check availability" button still saves a lot of back-and-forth over email.

3. A direct booking path on every screen

Booking platforms bring visibility, but they take a commission on every booking, and the guest relationship belongs to them. The website's job is to turn returning guests and Google visitors into direct bookings. That means either a booking request form or a connected booking engine, plus one-tap WhatsApp, phone and email buttons. On mobile, a sticky contact bar works well.

4. Every language in its own URL

A Turkish family, a British couple and a German group all trust a booking page more in their own language. For SEO, give each language its own address (/de/, /tr/ and so on), use proper hreflang, and translate menus, forms and confirmation emails as well as the page text. A plugin like WPML handles this in WordPress. Remember that right-to-left languages need their own layout checks.

5. Location and local context

Guests want to know where they'll actually be: how far the beach is, how to get there from the airport, and what's within walking distance. An embedded map, simple directions and a short area guide keep visitors on your site while they plan. They also give Google more local signals to work with.

6. Trust details

Show reviews from past guests and link to your profiles on review platforms. Publish check-in times, cancellation rules and house rules, and show a licence number, a real address and the people behind the business. For a small hotel, this is what makes booking directly feel safe.

7. Speed on mobile data

A heavy theme loses guests before the first photo loads. Page caching, optimised images, fewer third-party scripts and lean CSS let a site look luxurious and still feel fast. On a multilingual WordPress site I helped optimise, the median mobile PageSpeed score went from 51 to 75 on the same page. That shows how much room for improvement most sites have.

8. Local SEO for every season

Write pages for the searches guests actually type, like "villa with private pool in Kyrenia" or "beach hotel near Famagusta". Add Hotel / LodgingBusiness structured data and keep publishing seasonal content, so you show up before travellers settle on a platform.

When an app is worth it

For a larger hotel or a group of villas, a companion app can add digital check-in, room-service requests, local recommendations and return-visit offers. With Flutter, one codebase can share content and APIs with the website, which keeps both in sync.

FAQ

Can the website take bookings directly?

Yes. It can send booking requests to the owner, show live availability or connect to a booking engine. It depends on how many units there are and how many bookings come in.

Do I still need booking platforms?

Usually, yes, because they bring visibility. Your own site works alongside them and turns returning guests into direct bookings.

Can the owner update prices and photos?

With WordPress and Elementor, yes. Seasonal prices, photos and offers can be edited in every language without calling a developer.

Originally published on ehsanabedi.com. Running a hotel or villa in North Cyprus? See my web design services.

What Really Decides the Cost of a WordPress Website (8 Factors I Explain to Every Client)

Ehsan Abedi — Sat, 17 Oct 2026 09:29:05 +0000

"How much does a website cost?" is the first question almost every client asks me. It is a fair question, but there is no honest one-number answer. A one-page site for a new café and a multilingual property portal with hundreds of listings are both "websites", yet they are completely different projects.

I am a web designer and WordPress developer based in Famagusta, North Cyprus. Here is the breakdown I walk clients through, so they understand what they are paying for and can compare quotes fairly. If you are a developer, it may also help you explain your own pricing.

Why a website has no fixed price

A website is closer to a tailored suit than a product on a shelf. One business wants phone calls, another wants online bookings, a third needs four languages for international buyers. The price follows the work, so the clearer the goals, the clearer the quote.

The 8 factors that shape the cost

1. Pages and sections. A focused business site usually needs a home page, an about page, one page per main service and a contact page. Every extra page adds design, content and testing time. Start with what customers really need; add the rest later.

2. Theme or custom design. A good WordPress theme adapted to the brand is the fastest route to a professional look. A fully custom design takes longer, but pays off in crowded markets like real estate or hospitality.

3. Languages. In North Cyprus, many businesses serve customers in English, Turkish, German, Russian or Persian. Every language means translated pages, menus and forms, and right-to-left languages need their own layout checks.

4. Features and integrations. A contact form or WhatsApp button is simple. Booking, property search filters, an online shop, payments or a CRM connection need more planning and testing. Split the list into "day one" and "later".

5. Content. Ready text and photos make a project move faster. If they need writing, translating or photographing, that belongs in the plan, because content is what turns visitors into enquiries.

6. Speed and SEO setup. Titles, structured data, a sitemap, Search Console and performance work decide whether anyone finds the site and whether it opens quickly on a phone. I treat this as part of the build, not an extra.

7. Hosting, domain and email. Small yearly costs, but quality matters. Cheap, slow hosting can undo all the work that went into the design.

8. Care after launch. WordPress core, plugins and content need regular updates and backups. A simple care plan keeps the site secure and makes small changes easy.

One-off costs vs yearly costs

I always split the budget in two:

One-off: planning, design, build, content and launch
Yearly: domain, hosting, email and care

Knowing both from the start means no surprises, and it makes quotes from different people easy to compare.

How to get an accurate quote

Before the first call, prepare:

What the site should achieve: calls, messages, bookings, sales or trust
A rough list of pages and languages
Two or three websites you like, and why
Features needed now vs later
Your ideal launch date

Keeping the budget under control

Launch the core first, then add pages in a second phase
Choose a platform you can edit yourself (WordPress + Elementor), so small text and price changes cost nothing
Reuse what works: good photos, texts and logos can often be refreshed instead of recreated
Redesign instead of rebuilding when the current structure is sound

FAQ

Is a cheap website a bad idea?

Not necessarily. A simple site is a great start if it is fast, works on phones and is set up for Google. The expensive mistake is a site that looks fine but never brings in enquiries.

Do I pay every year?

The design and build are paid once. Domain, hosting, email and care are the yearly costs that keep the site online, fast and secure.

Can I add languages or features later?

Yes. A WordPress site on a clean structure can grow with the business, so languages, booking or a shop can come when you are ready.

Originally published on ehsanabedi.com. Planning a website or a Flutter app in North Cyprus? See my web design services.

Core Web Vitals for WordPress: A Plain-Language Guide

Ehsan Abedi — Fri, 16 Oct 2026 13:49:01 +0000

Core Web Vitals are Google's way of measuring how a website feels to a real visitor: how quickly the main content appears, how fast the page reacts to a tap, and whether things jump around while it loads. Good scores help your pages in search, but more importantly they keep visitors happy enough to stay, read and get in touch.

I build and speed up WordPress websites for businesses in North Cyprus and abroad. In this guide I explain the three Core Web Vitals in plain language, how to check your own site in a few minutes, and the WordPress fixes that make the biggest difference.

The three Core Web Vitals in plain language

Largest Contentful Paint (LCP) measures how long it takes for the biggest visible element, usually the hero image or main heading, to appear. Google considers 2.5 seconds or less to be good.

Interaction to Next Paint (INP) measures how quickly the page responds when someone taps a button, opens a menu or types in a form. A good score is 200 milliseconds or less, which feels instant.

Cumulative Layout Shift (CLS) measures how much the layout moves while the page loads. You know the feeling: you go to tap a link and an image pushes it down at the last moment. A good score is 0.1 or less.

How to check your website in five minutes

Open Google PageSpeed Insights and enter your homepage address.
Look at the mobile tab first, because most of your visitors arrive on a phone.
Check the top section, which shows real-visitor data when your site has enough traffic, and the lab score below it.
Run the test a few times. Scores vary from run to run, so the typical result matters more than a single number.
Repeat for one service page and one blog post, since different templates often behave differently.

If you use Google Search Console, the Core Web Vitals report groups your pages and shows which ones need attention, based on real visits over the last weeks.

WordPress fixes for a faster LCP

Serve images in WebP at the size they are actually shown, not straight from the camera
Load the hero image first and lazy-load only the images further down the page
Use page caching and a CDN so pages are delivered from a server close to the visitor
Host your fonts locally and load only the weights you really use

WordPress fixes for a better INP

Slow reactions usually come from too much JavaScript: sliders, chat widgets, tracking scripts and plugins that all load on every page. Remove the plugins you no longer need, load scripts only on the pages that use them, and delay third-party scripts until the visitor interacts with the page. On this website, for example, Google Analytics loads only after the first scroll or tap, so it has no effect on the speed score at all.

WordPress fixes for a stable layout (CLS)

Give every image and video a width and height so the browser reserves the space
Reserve room for banners, cookie notices and embedded maps before they load
Load web fonts in a way that does not reflow the text when they arrive

Speed without losing a beautiful design

A fast website does not have to look plain. The goal is to keep the visual experience your brand deserves, including large photos, video and smooth animations, while removing everything that slows the page down behind the scenes. That is exactly what I did for a multilingual real estate website, which reached 90+ on desktop with its luxury design intact. Read the full story in How I Took a Multilingual WordPress Site to 90+ on Google PageSpeed.

If your website feels slow and the design is also showing its age, a refresh may be the better route. See Website Redesign: 7 Signs It Is Time for a Refresh.

When a mobile app is the next step

A fast website wins new visitors from Google. For customers who come back often to book, order or check updates, a mobile app goes one step further: it opens instantly from the home screen and can remind them with notifications. With Flutter, I build one app for both Android and iPhone that reads the same content from your WordPress website through the REST API, so you keep managing everything in one place. Read Flutter App Development: From Idea to Launch, Step by Step to see how it works.

Frequently asked questions

Do Core Web Vitals affect my Google ranking?

Yes, they are part of how Google evaluates page experience. Relevant, helpful content still matters most, but between similar pages a faster, more stable one has an advantage, and visitors are more likely to stay.

Why is my mobile score lower than my desktop score?

PageSpeed Insights tests mobile with a slower simulated phone and network, so mobile scores are almost always lower. Focus on improving the mobile result, because that is how most people visit.

Can a caching plugin alone fix Core Web Vitals?

Caching helps a lot, but it cannot fix oversized images, heavy plugins or layout shifts. The best results come from combining caching with lean pages and well-prepared images.

Can you speed up my existing website without redesigning it?

Often, yes. Many sites improve noticeably with image optimization, caching and plugin cleanup while the design stays exactly as it is.

Originally published on ehsanabedi.com. Need a fast WordPress website or a Flutter app? See my web design services.

Website Redesign: 7 Signs Your Business Website Needs a Refresh

Ehsan Abedi — Thu, 15 Oct 2026 14:29:08 +0000

A website redesign is one of the best investments a growing business can make, but knowing when the time has come is not always easy. Your website may still work, yet quietly lose visitors to competitors with faster, clearer and more modern sites. In North Cyprus, where customers compare businesses on their phones before they ever call, an outdated website can cost enquiries every single week.

I redesign and build WordPress websites for businesses here and abroad. These are the seven signs I look for, and how a redesign can turn your website into your best salesperson again.

1. It is hard to use on a phone

Open your website on your own phone. Do you need to zoom to read the text? Are the buttons small and close together? Do wide tables or images run off the screen? Most visitors arrive on a phone, often from a WhatsApp link or a quick search, and a site that feels awkward there loses them in seconds. A redesign starts with the small screen and works upwards.

2. Pages load slowly

If your pages take a long time to appear, visitors leave before they see what you offer, and Google notices too. Heavy images, old themes and too many plugins are the usual causes. A modern build with caching, optimized images and lean code can make a site feel quick while keeping it beautiful. I show how in How I Took a Multilingual WordPress Site to 90+ on Google PageSpeed.

3. The design no longer matches your business

Businesses grow: new services, a new logo, a more premium position. If your website still shows the business you were five years ago, it is underselling the one you are today. A redesign brings your brand, photos and message up to date, so the first impression matches the quality of your work.

4. You cannot update it yourself

Waiting for someone else every time a price or photo changes means your website is always a little out of date. With WordPress and Elementor, you edit texts, images and news yourself from a friendly dashboard. Read why WordPress is still the best choice for business websites for the details.

5. Visitors come, but enquiries do not

If people visit but rarely contact you, the path from interest to conversation is probably unclear. A redesign puts clear calls to action on every page: a WhatsApp button, a phone number visitors can tap, a short form and a simple explanation of what happens next. Small changes in structure often bring a noticeable rise in enquiries.

6. It speaks only one language

In North Cyprus your customers may write in English, Turkish, German, Russian, Persian or Arabic. A redesign is the perfect moment to add the languages that matter, each with its own address so Google can show it to the right people. My guide Multilingual WordPress Website: A Practical Guide with WPML explains how.

7. Google cannot find you

If you do not appear when people search for your service in Famagusta, Kyrenia or Nicosia, the problem is often technical: missing page titles, unclear headings, slow pages or no sitemap. A good redesign builds SEO in from the start, with clean structure, fast pages and Google Search Console set up so you can see how people find you.

How a redesign keeps what already works

A redesign should never throw away the Google rankings you have earned. Before anything changes, I list your existing pages, keep the addresses that already rank and set up redirects for any that move. Your content is carried over and improved, not lost, and the new site goes live only after it has been tested on real phones and computers.

The perfect moment to add a mobile app

A redesign is also a natural time to think about an app. If your customers book, order or come back often, a Flutter app gives them your business on their home screen, on both Android and iPhone from a single codebase. Built on a fresh WordPress website, the app can read the same services, products or listings through the REST API, so you manage everything in one place. Read Flutter App Development: From Idea to Launch, Step by Step to see how an app comes together.

Frequently asked questions

Will I lose my Google rankings after a redesign?

Not when it is planned carefully. Keeping existing addresses, adding redirects for changed ones and carrying over your content protects the rankings you already have.

Can my existing content be reused?

Yes. Good texts, photos and articles are moved to the new design and often improved along the way, so nothing valuable is lost.

Does my website stay online during the redesign?

Yes. The new website is built and tested separately, and your current site stays online until the new one is ready to launch.

Can you add a mobile app after the redesign?

Yes. A WordPress website built with the app in mind makes the next step easy: a Flutter app for Android and iPhone that shares the same content.

Originally published on ehsanabedi.com. Planning a website or a Flutter app? See my web design services.