Pitanja koja ljudi stvarno postavljaju

You describe the problem, I ask questions until I understand it, and by the end you have my honest read on whether it is a two-week job or a six-month one. No slides, no discovery document, no second call with a different person. If I am not the right person for it I will say so on that call rather than three weeks later.

Free, forty-five minutes, no obligation, and nobody follows up with a sequence of emails afterwards. The catch, such as it is, is that I am deciding whether I want the work as much as you are deciding whether you want me. Some of these calls end with me naming somebody else who is a better fit.

Three things. What platform and roughly what version — WooCommerce, which plugins are doing the heavy lifting, which gateway. Rough volume: orders a month, active subscribers, number of SKUs, approximate is fine. And the thing that is actually bothering you, in your own words rather than as a specification. If you have none of that to hand, come anyway; the questions are the same.

Me. There is nobody else. The person who estimates the work is the person who writes it, which is the entire argument for hiring one experienced developer instead of an agency — nothing is lost between the call and the code, and nothing is promised by somebody who will not have to build it.

Within 24 hours you get a short written summary of what I think the problem is, in writing, so you can show somebody else. If it is a fit, a scope and a price with it. If it is not, I say so and point you somewhere better. No follow-up sequence, no newsletter, no second email if you do not reply.

No, and that is the normal case. Most people arrive knowing what is broken rather than what it is called. Deciding the shape of the work is the part where an hour saves a month, and it is far cheaper to be wrong about it on a call than after somebody has started building.

Yes, send it over — a good deal of my recent work is under one, which is why some of it is missing from the portfolio. I do not need one to hear a problem described, but if your legal team wants it first that is fine and it does not delay anything.

Central European Time, and in practice it has not mattered — most of the last sixteen years has been US and UK clients. The booking page shows slots in your own timezone, and there is usually overlap with a US morning. For urgent work the timezone is an advantage: a European morning is the middle of a US night, which is when a broken checkout is cheapest to fix.

Use the urgent route, not the booking page — a consultation scheduled for Tuesday is the wrong shape for an outage. Before you write, take a screenshot of the error and note roughly when it started and what changed: a plugin update, a deploy, a host migration, a card expiring. That is usually enough to know where to look.

Triaged the same day, within eight hours, weekends included. Triaged means I have looked at it and told you what it is and what fixing it involves — not that it is fixed. Some things are fixed in that first look; a compromised shop usually is not.

Almost always a condition you do not have. A shipping country with no rate, a payment method only some customers see, a cart combination that trips a tax rule, or a logged-out session where a plugin assumes a logged-in one. The useful thing you can send me is one real failing order — the email, the time, the products — because reproducing it is most of the work.

Roll back the files if you have a clean backup and the shop is losing money — that is the fastest route to trading again. Be far more careful with the database: restoring it loses every order, customer and subscription change since the backup was taken, and I have been called in to recover from the rollback more often than from the update.

Nearly always. A white screen is a fatal error with display turned off, which is the correct setting for a live site and the reason it looks like nothing happened. The message is in the PHP error log, and your host can produce it in a minute. Send me that and the diagnosis is usually immediate.

Usually, and the sooner the better. Subscription systems do not fail loudly — they leak, and the first symptom is a revenue line that is quietly lower. While the payment tokens are still valid most of it can be collected retrospectively without asking customers to re-enter a card. Leave it long enough and the tokens expire, and then you are asking thousands of people to pay you again.

Recoverable in most cases, and more common than you would think. The two that matter are the hosting account and the domain registrar, because those are the ones nobody else can grant you — both have an ownership recovery process if the company is yours. WordPress admin, deployment keys and third-party services can all be rebuilt from server access. Start the registrar process today; it is the slowest.

If the shop is down, no. Weekends are included in the eight-hour triage, and a weekend outage is often the most expensive kind — it is when consumer traffic peaks and when nobody internally is watching. There is no out-of-hours surcharge for the first look.

The first look costs nothing, including at the weekend. After that it is the same hourly rate as planned work — there is no emergency multiplier, because charging more at the moment somebody has least choice is a way of being paid once. You get an estimate before anything is billed, and for a compromised shop you get the range up front since the depth is not knowable from outside.

It is a fair question and worth answering honestly. The risk is availability — one person can be ill or busy, and an agency has more people. What you get in exchange is that nothing is lost between them, the person who estimated the work is the person doing it, and there is no account manager relaying your question to somebody who then relays an answer back. I mitigate the availability side by documenting properly and not making the code depend on me being around.

Yes, and I prefer it. The useful part is being involved early enough to say when something will be expensive to build or will not survive contact with a phone — while it is still a Figma file rather than a finished design somebody has already approved.

Common, and it is roughly half the work I take on. It starts with reading what is there and telling you honestly whether it is worth continuing or worth restarting. Sometimes the answer is restart, and I would rather say that in week one than bill you for three months of working around somebody else's decisions.

Fixed where the scope is genuinely knowable, which it usually is after the code review. Hourly for open-ended work, emergencies and inherited codebases where nobody yet knows what is in there. What I will not do is quote a fixed price for something I have not looked at, because that price is either padded or wrong.

You should be able to, and the build is done so that you can. Documented, no unnecessary dependencies on tools only I have, deployment written down. If a developer cannot pick it up without me, I did it badly.

Regularly. Roughly half my last decade was white-label work behind agencies — your process, your project manager, and I do not appear in front of your client.

As current as the sync cycle, which is usually hourly for stock and daily for the catalogue. Where a specific line genuinely needs a live check — high value, low stock, prone to overselling — that one call can be made at add-to-cart while everything else stays scheduled. It is a per-field decision, not an all-or-nothing one.

The shop keeps trading on the data it already holds and the queued jobs retry when the ERP returns. Orders placed during the outage are held and pushed once it is back, with idempotency keys so nothing is duplicated. Data goes stale; nothing is lost.

Usually yes, and I will tell you honestly how much of my experience transfers. The integration patterns — ownership per field, identifier mapping, idempotent writes, reconciliation — are the same everywhere. What differs is the API, its limits and its documentation. My depth is greatest with NetSuite and Macolla; SAP and Acumatica I have worked with less.

For a straightforward catalogue and order sync, six to ten weeks. The variables are how clean the ERP data is, how many pricing rules exist, and how quickly someone on your side can answer questions about the data. Configurable products and multi-warehouse stock add time.

Usually it means something is querying the ERP during a page load, or a sync is making one call per record where it could batch. The fix is architectural rather than a tuning exercise: move the work into a queued job, batch the reads, and let the storefront answer from its own copy. That is the same change I made after my first real-time build fell over.

Not necessarily. Often the cheapest answer is to keep the connector for catalogue and orders, and build only the pricing resolution alongside it. Full replacement is worth it when several things are being worked around at once, or when someone is re-keying data daily regardless.

Yes, and it is a common way this starts. The first piece of work is usually a reconciliation report showing exactly where the two systems currently disagree, which tends to be more revealing than anyone expects.

Both, regularly. I take the website side and stay in my lane, which ERP consultancies generally appreciate because most web developers do not.

Often not, but it depends on your gateway, whether you keep the same gateway account, and how the old system stored payment methods. Stripe has a supported process for moving stored payment methods between accounts; PayPal billing agreements are considerably less portable. This is the first thing I establish, because it changes both the plan and the price. Anyone promising a seamless answer before looking at your setup is guessing.

Yes — that is the point of the approach. Three times now, with no interrupted payments. Billing continues while the migration runs on a clone, and the cutover happens only once two full test cycles agree.

If you only need gated content and recurring billing, PMPro does that well and moving costs money to stand still. If you need real products, coupons, reporting, physical fulfilment, or to sell things that are not memberships, WooCommerce Subscriptions is the better home. I would rather talk you out of a migration you do not need.

Yes, and it is more involved than it sounds. Recurring shipping rates, skip and delay, address changes mid-cycle, and stock reserved against upcoming renewals so the warehouse is not surprised. The billing is the easy half.

Almost always a retry without an idempotency key, or a webhook processed twice because the first response timed out. Both are fixable, and both leave a trail in the gateway logs that makes the cause obvious once someone looks. Refunding is the easy part; stopping it recurring is the job.

The classic import failure. Schedules have to be reconstructed from payment history rather than taken from a spreadsheet, otherwise everyone drifts to the import date. It is repairable after the fact, but it means recalculating each subscriber against what they were actually charged and when.

Common, and usually diagnosable quickly. The first step is comparing what your site believes against what the gateway believes — the gap is normally webhooks that failed and were never replayed, or a scheduler that stopped firing after an update. That comparison is a small fixed piece of work on its own.

Almost certainly, because most sites do nothing beyond the plugin default. A proper retry ladder, pre-emptive card expiry notices, and dunning emails that read like a person wrote them typically recover more revenue than any acquisition work at the same cost.

For a normal content or catalogue migration, a short read-only window at cutover — usually under an hour. For subscriptions or anything still taking orders, none: the new system is populated in advance and kept in step, with a delta sync at the switch. Zero downtime costs more, and for a shop it usually pays for itself in a single afternoon of not being closed.

Not necessarily. Password hashes differ between systems, but the old hash can usually be stored and verified once at the customer's next login, then transparently re-hashed. They log in as normal and never know. Where the old system used something unrecoverable, a reset is unavoidable and I will tell you before we start.

Usually. Direct database access is easiest, an API is fine, and where neither exists the data can often be extracted from the running site itself. It is slower and messier, and it is worth knowing that before you assume you are locked in.

A redirect map from every old URL to its new one, built before the move rather than reconstructed after complaints. Structure and metadata carried across, and Search Console watched for a few weeks afterwards. Migrations that lose rankings almost always lost them here.

Often yes, provided the old system still exists — which is the first thing to check and the reason I say never to delete it early. What is recoverable comes from the source; what is not has to be reconstructed, and I will be honest about which is which before quoting.

Counts reconciled by record type, financial totals compared against the source, and a sample of real records checked field by field — including the awkward ones you nominate, because you know which customers matter. If the verification does not agree, we have not finished.

Yes, and usually you should. One catalogue, one stock pool, different prices and visibility depending on who is logged in. The alternative — two separate sites — means two catalogues drifting apart and somebody maintaining both. Multisite is worth it only when the brands genuinely need to look different, which is how Moes Home was built.

The ERP owns it, the store caches it. Rules held in two places drift, and the version the customer sees should never be the guess. What the store keeps is a resolved copy, refreshed on a schedule, with a report showing where the two disagree.

Yes, and it is worth building properly. The rep searches accounts, switches into one, sees exactly what that customer sees including their pricing, and submits on their behalf — with the order recorded against both so history and commission stay correct. Reps also need to not see accounts that are not theirs.

By treating it as a different problem from parcel. Freight class, dimensional weight, liftgate and residential surcharges, and live LTL carrier quotes where the carrier supports it. Where a live rate cannot be obtained, the cart needs a defined fallback rather than a blank space — usually a quote request that goes to your sales desk.

Some will not, and that is worth accepting rather than fighting. The portal earns its keep on repeat ordering, stock checking and order history — the things dealers currently phone about that nobody enjoys answering. Expect the phone to stay for exceptions, and build the rep-ordering path so those calls still end up in the same system.

Common, and it does not always mean replacing it. Often the plugin handles gating and account tiers perfectly well and only the price resolution needs building alongside it. The audit tells us which, and I would rather extend what you have than sell you a rebuild you do not need.

Yes, and it is worth building properly rather than working around. The parent holds the subscription and the payment method; each child gets their own login, their own progress and their own certificates. The parent needs a view across all of them and the ability to switch. Sparketh works exactly this way.

Yes. The mechanics that matter are reclaiming a seat when someone leaves without destroying their completion record, letting a manager see progress across the team, and handling the renewal when the headcount has changed. Seat pools are straightforward; the lifecycle around them is where the work is.

If courses are part of a wider WordPress site and the assessment needs are moderate, LearnDash. If education is the business and you need gradebooks, real assessment tooling or institutional roles, Moodle — usually with WordPress in front for the public site and the purchase, connected by single sign-on. Running Moodle when LearnDash would do is a lot of infrastructure for no gain.

If you are only selling access, Paid Memberships Pro is lighter and adequate. If you sell anything alongside the courses, need coupons and proper reporting, or want seat quantities to behave like product quantities, WooCommerce Subscriptions is the better home. Plenty of sites start on the first and move to the second, and I do that migration regularly.

Usually yes, and progress is the part to insist on. Courses and learners move easily; completions, quiz attempts and issued certificates are what get dropped by a careless migration, and learners notice immediately. It needs mapping before anything moves and verifying afterwards against a sample of real accounts.

Then the system needs to be defensible, not just functional — verifiable issuance, an audit trail, rules about who can earn one, and a record that survives platform changes. I built exactly this at The ObG Project, where the document allowed clinicians to renew their specialisation, and the constraints shaped the whole build rather than being added at the end.

Count your combinations honestly, then count how many photographs you already have. If combinations are in the dozens and your product has separable parts, type two solves it for a fraction of the cost of type four. If you sell made-to-measure, nothing below type four will do. I would rather talk you down a tier than sell you the expensive one.

For type one, usually yes. For layered compositing, only if the shots were taken from an identical camera position with identical lighting, which is rarely true of photography shot for a catalogue. Reshooting the parts is often unavoidable, and it is better to know that in week one.

If you need a visual and nothing else, buy one — I will tell you which. The reason to build is when the configuration must drive price, stock and manufacturing. Hosted tools generally hand your order system a description rather than a specification, and someone in your office ends up retyping it.

Types one and two, trivially. Frame spinners need care over image weight and preloading, since thirty-six images per variant is a real payload on mobile data. WebGL runs well on modern phones but needs a performance budget set early and honoured, not discovered at the end.

That is part of the build, not an afterthought. A configuration should arrive in your system as parts, dimensions and a price, in a form production can work from. If it arrives as a paragraph of text, the configurator has moved the data entry rather than removed it.

Because they measure different things. Lighthouse simulates a page load on one machine under assumed conditions. Google's assessment uses field data from real Chrome users at the 75th percentile over a rolling 28-day window — real phones, real networks, real caches. A fast lab score alongside a failing field assessment usually means your visitors are on slower devices or connections than the simulation assumed.

I will not give you a number before looking, and anyone who does is guessing. What I can say is where the time is going after a couple of days of profiling, and roughly what each fix is worth. Sites carrying a heavy plugin stack and an unoptimised database usually have a great deal available; sites already tuned have less, and I will say so rather than sell you a pass.

It may help, and it is not the reason to do it. Core Web Vitals are confirmed as a ranking signal but they are one of many, and they work as a tiebreaker between comparable pages rather than a way to beat better content. The reliable return is conversion — people abandon slow checkouts regardless of where you rank.

Usually a long way, yes. Caching layers, database work, asset handling, plugin reduction and server tuning go a considerable distance without touching the design or the build method. Where that runs out, I will tell you what the remaining gain would cost and let you decide whether it is worth it.

Common, and it has a specific cause: logged-in pages cannot be served from the page cache, so every one is generated fresh. Everything the theme and plugins load on a normal page now happens on every request, with the database work included. It is very fixable, and it is usually where the real money is on a membership or ecommerce site, because those are the pages people spend money on.

Visitors feel it immediately. Search Console takes about four weeks, because the field data behind the assessment is a rolling 28-day window and needs time to reflect the change.

Usually the same day for the common infections. The tooling for finding modified files is far better than it used to be — what once meant comparing dozens of plugins by hand is now a single verification pass. What varies is how deeply it is embedded and whether your host has suspended the account.

Eventually, yes, and I will tell you that honestly. But not today and not instead of opening the shop. Emergency work gets you trading; the rebuild is planned properly afterwards, usually alongside the update backlog that let this happen in the first place.

Not through the same route, because closing it is part of the job. Through a new route, only if something else goes unpatched — which is what the hardening and monitoring work is for.

Once the site is genuinely clean, the review request typically clears within a few days, though Google sets the timetable and not me. Reindexing after SEO spam takes longer, and I will be straight with you about what has been lost rather than promising a full recovery.

For a blog, use them — I mean that. The cheap services scan files, remove what matches a signature and submit a blacklist removal, which is genuinely the right service for a site with no orders in it. A shop needs the payment path verified, the order and customer data checked for what was reached, and the processor relationship protected. Different job, different amount of time.

Yes, and it is the most urgent version of this. A processor that suspects a skimmer will hold funds or close the account, which hurts far more than the malware did. Getting the payment path demonstrably clean and documented is what resolves that conversation.

Yes. A scan and a written finding is a small fixed piece of work on its own, and plenty of people buy that first. If it comes back clean you have paid for peace of mind, which is a reasonable thing to buy.

Regularly. White-label, your process, your client relationship. I do not appear in front of your client, and I will not tell them their previous developer left the door open.

Almost always one of two things: a known vulnerability in a plugin that was not updated, or a password that was reused somewhere else and turned up in a breach. Very rarely anything clever or targeted — most compromises are automated, scanning every site on the internet for the same handful of holes. Part of the cleanup is establishing which it was, because if you do not know, you cannot be sure it is closed.

The first question is usually answerable: access logs, database query patterns and what the injected code was actually doing together show whether data was reached or only the site defaced. The second is a legal question, not a technical one — GDPR and most US state laws have notification deadlines measured in days. I give you a written finding of what I can establish and what I cannot, and your lawyer decides what it obliges you to do. Do not let anyone tell you the answer is obvious either way.

A security plugin is a smoke alarm, not a fire door. It is good at noticing changed files and blocking crude login attempts, and genuinely worth having for that. It cannot stop a request that looks legitimate — an authenticated upload through a plugin with a file-handling bug is, to the firewall, a user doing a normal thing. Updates close those holes; the plugin only tells you somebody walked through one.

Slower, not worse, and it is usually the right call — a suspended site is not sending spam or serving malware to your customers while you deal with it. The first step is getting read access back, which hosts will generally grant for cleanup even while the site stays offline publicly. Ask for that specifically rather than asking for the suspension to be lifted; you will get it faster.

This is the one case where speed matters more than tidiness. Take checkout out of service rather than leaving it collecting, preserve the logs before anything is cleaned, and tell your payment processor early — they are far more helpful to a merchant who reported it than to one they discovered. If you take cards directly rather than redirecting to the gateway, there is a PCI dimension to this and you want that conversation started, not avoided.

For a shop carrying real orders and customer data, yes, and it costs a fraction of a cleanup. The findings are almost always unglamorous: a plugin two years out of date that nobody owns, admin accounts belonging to people who left, backups that have never been restored to check they work. For a brochure site with no orders in it, honestly, keep things updated and spend the money elsewhere.

Only if you know when it started, and most people find out it has been months. Restoring to a date before the break-in loses every order since, and restoring to one after it puts the malware back. It also restores the hole they came through, so it happens again within days. Backups are for hardware failure and bad deploys; a compromise needs the entry point found first, which is a different job.

Frequently not, and I will say so. If the task has a right answer that can be looked up or calculated, a query or a rules engine is faster, cheaper and correct every time. Language models earn their cost where the input is messy, unstructured or written by a human — which is a real category, just narrower than the current enthusiasm suggests.

That is part of the feasibility work, because it is genuinely different from ordinary software. Cost depends on how much text goes in and out, how often, and which model. It can usually be reduced substantially by caching, by using smaller models for simpler steps, and by not calling a model where a query would do. You get a monthly figure at your real volume before committing.

Depends how strict the requirement is. Providers offer terms covering data handling and retention that satisfy many businesses. Where they do not, a model can run on infrastructure you control, at higher cost and lower capability. This decision shapes everything else, so it is settled first.

By building an evaluation set — real questions from your business with known good answers — and running it whenever anything changes. Without that you are relying on someone noticing, and quality tends to degrade quietly. This is the part most implementations skip and the reason they disappoint after a few months.

Into what you have, almost always. These features are most valuable when they can see your real data — your orders, your documents, your customers — and that argues for building where the data already lives rather than beside it.

Because the failure modes are engineering failure modes, not novel ones. Deciding what a system is permitted to do, designing for hostile input, building in an approval step before an irreversible action, and modelling running cost before committing — that is the same discipline as building a payment system, and I have sixteen years of that. What I will not do is claim a longer track record with these specific tools than I have.

Sometimes not, sometimes yes. It depends on your gateway, whether you keep the same gateway account, and how PMPro was set up. Establishing this is one of the first things I do, because the answer changes both the plan and the price. Anyone who promises you a seamless answer before looking at your setup is guessing.

Three, honestly. Switch to a gateway the plugin still supports, which is the smallest change and sometimes the right one. Move to a platform that supports your gateway. Or stay and lose automatic billing, which is not really an option for anyone with more than a handful of members. Which is cheapest depends almost entirely on whether your stored payment methods can carry across, and that is the first thing I check.

The migration itself is usually a few weeks. The clean-up of the old data beforehand is the variable, and on a site that has been running for years it can be longer than the migration. Then two billing cycles of monitoring before I consider it finished.

Yes. Billing does not pause. That is the whole point of the approach — I have done it twice with no interrupted payments, on top of similar work moving thousands of subscribers at ProgressiveChristianity.

Only if you need what it gives you: real products, coupons, reporting, an ecommerce ecosystem, or the ability to sell things that are not memberships. If you only need gated content and recurring billing, PMPro does that well and migrating is spending money to stand still.

The rollback is tested on the clone before we go. If the migration misbehaves we restore and nobody's billing is affected, because the gateway side is not touched until the WordPress side is verified.

Faster than the full process above, and I will be honest about what gets cut to do it. The data clean-up is what compresses; the clone run and the tested rollback do not, because those are what stop an emergency becoming a disaster. Tell me the deadline on the first call and I will tell you whether it is achievable.

Yes, regularly. About half my last decade was white-label work behind agencies. I work to your process and I do not appear in front of your client.