DEV Community: Ehsan Abedi

Building a Clinic Booking App in Flutter: Slots, Reminders and Privacy

Ehsan Abedi — Thu, 05 Nov 2026 13:43:29 +0000

Clinic booking apps look like a calendar with a "Book" button. In practice, the hard parts are elsewhere: how you model free time, how you stop two patients from taking the same slot, how reminders reach people in the right time zone, and how you keep health data out of places it shouldn't be.

I'm a freelance Flutter and WordPress developer in Famagusta, North Cyprus, where many clinics treat local patients and visitors from abroad in the same week. Here is how I structure these apps.

Model availability, not appointments

Storing only appointments and "calculating" free time on the client gets messy fast. I keep three things on the server:

Schedules: each practitioner's working hours per weekday, per branch.
Exceptions: holidays, sick days, a surgery that blocks the afternoon.
Bookings: practitioner, branch, start, end, treatment, status.

Free slots are generated on the server for a requested day: working hours minus exceptions minus existing bookings, cut into pieces of the treatment's duration plus a buffer. The app only displays what the server returns.

Never trust the client with the last slot

Two patients tapping the same 10:30 slot at the same moment is not a rare edge case on a Monday morning. The booking must be created in a transaction (or with a unique constraint on practitioner + start time) on the server. With Firestore, that means a transaction that reads the slot document and fails if it already exists. With Supabase / Postgres, an exclusion constraint on a time range does the job elegantly:

ALTER TABLE bookings
  ADD CONSTRAINT no_overlap
  EXCLUDE USING gist (
    practitioner_id WITH =,
    tstzrange(starts_at, ends_at) WITH &&
  ) WHERE (status IN ('pending', 'confirmed'));

The app then simply handles the error with "This time was just taken, here are the next free times".

Time zones: store UTC, show local

Patients book from abroad before they travel. Store starts_at in UTC, show it in the clinic's time zone with the zone name visible ("10:30, Cyprus time"), and schedule reminders from the server, not with local notifications calculated on the phone. A reminder the day before and a short one two hours before cuts no-shows noticeably.

Forms before the visit

Intake forms are where privacy matters most. My rules:

Collect only what the clinic actually needs.
Store answers server-side with strict access rules (staff role only), never in local storage or analytics events.
No health details in push notification text: "You have an appointment tomorrow at 10:30" is fine, the treatment name is not.

One codebase, two front doors

New patients usually find the clinic through Google and book on the website, while returning patients use the app. Both talk to the same booking API, so the calendar is always the single source of truth. Flutter covers Android and iOS from one codebase, and the website can be WordPress with a small booking front-end calling the same endpoints.

The business-side version, for clinic owners, is here: Clinic Appointment App in North Cyprus: Fewer No-Shows, Happier Patients. How do you handle slot collisions in your booking apps?

Taking Over an Unfinished Flutter App: My Audit Checklist (Security First)

Ehsan Abedi — Tue, 03 Nov 2026 17:18:22 +0000

"The app is 80% done, the previous developer stopped answering, can you finish it?" If you freelance long enough, you get this message. Sometimes the project is in good shape. Sometimes the last 20% is really 70%. And sometimes the repository itself is a risk to your own machine.

I'm a freelance Flutter and WordPress developer in Famagusta, North Cyprus. This is the checklist I go through before I quote, in the order I do it.

1. Don't run it yet: read it in isolation

The first rule: a repository from a stranger is untrusted code. Fake "fix this bug in our repo" tasks are a known way to steal SSH keys, browser cookies and saved passwords from developers. So the first pass is reading, not running, and anything that executes happens in a throwaway environment (a GitHub Codespace on a separate account, or a VM), never on the laptop that holds my client logins.

Things I read before any flutter pub get or gradle task:

android/build.gradle, android/app/build.gradle and settings.gradle: anything that calls exec, commandLine or downloads scripts at build time.
android/gradle/wrapper/gradle-wrapper.properties and the wrapper JAR: does the distribution URL point to services.gradle.org?
ios/Podfile and any "Run Script" build phases in the Xcode project.
pubspec.yaml: git dependencies pointing to unknown forks, or path dependencies outside the repo.
.vscode/tasks.json: a task with "runOn": "folderOpen" runs the moment you open the folder. Open unknown projects in Restricted Mode.
Any package.json (web tooling, Firebase functions): preinstall / postinstall scripts.

Only when that looks clean do I build, and still in the isolated environment. The APK it produces can then be tested on a spare phone or a cloud emulator.

2. Secure what belongs to the client

Before touching code, I make sure the client actually owns their project:

Git repo in their organisation, not the previous developer's personal account.
Google Play Console and Apple Developer accounts in the client's name.
Owner access to Firebase / Supabase / the backend, plus API keys for maps, payments and push notifications.
The Figma file and assets.

If any of this is missing, that is the first milestone, because without it nothing else is safe to build on.

3. Measure the real state

Then the honest part. I run through:

flutter analyze and the number of warnings (and whether analysis_options.yaml silences everything).
Flutter / Dart SDK constraints vs. current stable, and flutter pub outdated.
State management: one consistent approach, or three mixed together?
Secrets in source: API keys or passwords committed in Dart files or google-services.json for the wrong project.
Tests: any at all? Do they pass?
Every screen on a real device: which features work, and which only look finished.

The output is a short written report for the client in plain language: what works, what needs fixing, what is missing.

4. Finish, refactor or rebuild

Most rescues end up in one of three buckets:

Situation	Recommendation
Clean structure, missing features	Finish as is
Works, but features break each other	Refactor key modules first, then finish
Weak foundation or very old SDK	Rebuild, keeping designs, backend and data

Rebuilding sounds expensive, but it is often cheaper than fighting a codebase where every change breaks two other screens.

5. Make the next handover painless

Whatever happens, I set the project up so the client is never stuck again: weekly pushes to their repo, regular test builds they can install, store accounts and keys in their name, and a short README that explains how to build and release.

I wrote a non-technical version of this for business owners here: Unfinished App? How to Rescue a Half-Built App and Launch It. If you've taken over a project that turned out to be a trap, I'd love to hear what you check first.

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.