DEV Community: XAVER

When WordPress breaks: a quick fix and a better option

XAVER — Sat, 05 Sep 2026 06:42:42 +0000

In the space of a month we had two new clients for the same reason: their WordPress site suddenly stopped working after an automated update. Both sites were inaccessible via the admin. Both came back online the same day.

What went wrong

Automated core or plugin updates are handy. They also carry risk. An incompatible update can break PHP code, trigger a fatal error, or leave the site in a maintenance state. When that happens the admin can be unreachable and the regular dashboard fixes are impossible.

How we fixed it

We worked the old-school way and went straight to the fileserver. Short version:

access the server via SFTP or the host control panel
rename the plugins folder in wp-content to disable all plugins
move any mu-plugins or custom files out of the root temporarily
restore a recent backup of core files where needed, or replace the failing update
check error logs and PHP version, then re-enable plugins one at a time to find the culprit
fix file permissions and clear caches

That process let us get admin access back and bring both sites online the same day. One client chose to rebuild; the other stayed on the fixed site.

Options and likely cost

We give two clear options when we arrive:

Quick restore and repair. Get the existing site running and stable. This is tipically a small and affordable job.
Rebuild and migrate. Move off WordPress to a modern build we host and maintain. If you choose this path we can include the quick restore at no extra charge and use your previous site as source of content and inspiration.

Why consider moving away from WordPress

WordPress is excellent for a simple online presence and rapid setup. It is less suited to complex, high performance or highly bespoke web apps. After a year or two many sites either grow beyond what WordPress handles well, or suffer from plugin sprawl and update fragility.

If your site is mainly marketing content, a lightweight static or headless approach can be faster, cheaper to host, and easier to maintain. If you need custom workflows or heavy integrations a purpose built web app will be more reliable.

What we recommend

Work with someone that builds websites for a living. DIY and friends may get you a website that doesn't work for you.
Keep your plugins under control.
Once per year, get your site reviewed.

We don’t maintain WordPress sites routinely, but we know how to restore them quickly and how to rebuild them cleanly away from WordPress when that makes sense. Both approaches save you time and reduce risk.

How we used three AI models in Taranaki Business Showcase

XAVER — Thu, 20 Aug 2026 21:42:52 +0000

Last week we held a stand in Taranaki Business Showcase, organized by Taranaki Chamber of Commerce at Plymouth International.

We were wondering what to prepare for the occasion:

Pop-up banner printed by Graphix? Yes.
Business Cards designed by Idyllic? Yay!
Lollies? yeah nah, chocolates are better!
Leaflets? Merch? Nah.
AI Interactive Kiosk? Oh! That will be fun to have!

So we built it! A kiosk whose purpose was to collect business card information in an efficient and memorable way by creating a WOW! moment to those that decided to "give it a try" using simple business tools: One Webcam, One screen and Three different AIs.

Our webcam was live waiting for someone to put their business card in front of it. When that happened, then our first AI (gemini-3.1-flash-lite) would receive a shot and read the card to distinguish: name, email, company, address and industry, among other details.

Card information being scanned in real time with a regular webcam

Once the card was detected and first details were confirmed, the captured image would now be sent to two new AIs: to gemini-3.5-flash to give a second deeper read to the card and get all details confirmed and extended; and to gemini-3-pro-image-preview to re-stage the card into a trade-matched interior aligned with the cards' brand details and industry. Note that our logo was embedded as watermark, AI was not needed for that trick!

Final result: information understood, card in a contextualized background, ready to send via email.

Surprised visitors were very keen to receive the output to their emails, and a single click did the job: Send an email to their address captured by the kiosk, with the original shot and the restaged one, closing the whole loop within a minute.

Sample of business cards scanned and the staged results

How did it go?

Really well! During the event we scanned 35 cards and digitalized their contact details on the spot. And whilst I was busy with spectators, my 8-year-old helpers collected a card from all the other stands, which I personally scanned via our kiosk the day after at record speed, we now have 85 new quality local leads that can learn more from us.

When curiosity kicked in, we found out that it also worked with products, magazines and Ooshies!

Is AI relevant for your business?

As always, it depends. If you rush me: there's likely a handful of good use cases for each business, and thousands others that will be a distraction. In this simple example we used three different AIs because they served well to the particular task we intended, but most other AI models would have been a wrong choice.

Whereas the title of this post focuses on how we used AI, the important bit is to realize that the barrier to materialize your ideas has dropped. Two years ago it would have been impossible to build such a tool, secure and production-ready, in a couple of days. With a regular webcam we could recognize an arbitrary object, read a stranger's business card, re-stage it under a studio light, in a branded context or in front of Mount Taranaki, watermarked with our logo and sent to them on the spot.

If you have an idea that was impossible a few years ago, and it still sounds impossible today, come for a coffee and we'll work together to get rid of the im.

How we built TipJar.nz in 6 weeks: Our first Minimum Viable Product in Taranaki for Digital Payments

XAVER — Sun, 28 Jun 2026 23:42:01 +0000

TipJar.nz is a simple digital payments platform for schools, clubs and community groups across Aotearoa; think Eftpos without the terminal. You create a "Jar", generate QR codes and payment links, share them around an event, and see donations arrive on a live dashboard. We shipped a production MVP in six weeks to prove the concept, and the project was later picked by Venture Taranaki and presented at a public Showcase in May 2026.

What we set out to prove

For an Minimum Viable Product we had three clear goals:

Remove barriers to entry: no hardware, no long contracts, no complex setup.
Enable multiple payment points from one fundraiser.
Keep compliance and risk small so we could launch quickly and safely.

Six-week plan

We organised the process into weekly deliverables so we could show working software fast and iterate with real users.

Week 1: Product & design: Define and design core functionality: create Jar, generate QR, pay, dashboard.
Week 2: Payments integration: Integrate a card processor and ensure that payment flow was possible and reliable.
Week 3: Core backend: Users, Jars, QR records, Payers, Payouts and Email notifications.
Week 4: Frontend & QR generation: Public payment pages, QR code generation (SVG/PNG), printable assets and share links.
Week 5: Dashboard & live updates: Payment status, subscriptions, basic accounting export and live updates for events.
Week 6: Testing & launch: Staging testing, onboarding a handful of local groups, fix feedback, deploy and public launch.

Technical architecture

We made pragmatic choices to reduce build time, keep costs low and leave room to scale later.

Frontend: Simple is better, no fancy effects and a structure that is proven to work well for mobile phones and desktop.
Backend: All our projects are built in Ruby on Rails, famous for being the choice for startups that require speed and reliability.
Payments: We used Stripe, a worldwide payment processor for secure card handling and payouts.
QR codes & links: Each Jar has a unique public URL. We generate QR codes for the jar URL and optionally append location or point‑of‑sale parameters so organisers can track which QR code was used.
Hosting & deployment: The site is hosted in Sydney in AWS, we plan to move it to New Zealand early 2027.

UX and product choices that mattered

One Jar, many QR codes: A Jar represents an organisation. You can print a QR for each event, booth or activity but all payments map back to the same Jar.
Fast setup: Create a Jar in under a minute, no credit card for signup. Reducing friction was essential for adoption by volunteer organisers.
Transparency: Live donor list and the ability to export transactions made it easier for treasurers to reconcile and for organisers to follow up.
Share options: QR for print, short links for SMS/email, and copyable payment links for social channels.

Testing, launch and early validation

The project was selected by Venture Taranaki as a promising local initiative, and we presented TipJar.nz at a public Showcase in May 2026. That public demo was useful for getting feedback from other community organisations and potential partners.

What we learned

Start narrow: Solve one problem very well. For us that meant focusing on fast QR payments before adding subscriptions, fundraising tiers, payer profiles.
Track everything: Recording where payments come from (which QR) and why (payment metadata) powers follow‑up and improves collection rates.
Design simple: Simple language, minimal setup and printable assets matter. Many organisers are time‑poor and tech‑light.
Iterate with real users: Run a few real events before a big public launch to find edge cases in reconciling fees, refunds and disputed charges.

Next steps

For TipJar.nz the next phases are improving onboarding, adding better reporting for treasurers, and adding integrations with common accounting tools. We’ll keep iterating based on feedback from clubs and schools across Aotearoa. We are seeing Jars being opened all round New Zealand for different purposes.

If you want to try it, visit tipjar.nz or get in touch for a 15‑minute walkthrough. If you’re a developer or organisation planning a similar MVP and want the technical notes or schema we used, get in touch.

Why Ruby on Rails is Still a Great Choice in 2026

XAVER — Fri, 05 Jun 2026 18:55:29 +0000

Why we still choose Rails at XAVER

Ruby on Rails remains one of the fastest ways to move from idea to a reliable product. At XAVER we’ve built dozens of apps with Rails and keep coming back to it because its conventions reduce boilerplate, its testing culture keeps code maintainable, and its ecosystem covers a huge range of real-world needs.

How XAVER uses Rails

We use Rails across the project lifecycle: rapid prototypes and MVPs to validate ideas, API backends for single-page and mobile clients, and full-featured platforms that need robust admin interfaces, background processing, and storage. Typical patterns we rely on:

Service objects and clear boundaries to keep controllers thin and make AI or external integrations replaceable.
Background jobs for long-running tasks such as model inference, batch processing, and async webhooks.
ActionCable and streaming to surface partial or streaming responses to users while AI tasks run.
ActiveStorage and attachment handling for media pipelines that feed models or store results.
Test suites and CI to keep fast iteration safe as features and models evolve.

Rails and AI: practical fit, not hype

Rails is a good match for AI-enabled products because it manages the plumbing so teams can focus on modelling and UX. In practice at XAVER we integrate AI like this:

Call external model APIs (OpenAI, Anthropic, private model endpoints) from well-tested service classes and push heavy work into background jobs so requests remain snappy.
Cache model outputs and embeddings where appropriate to control costs and latency, and use job batching for bulk embedding or retraining tasks.
Stream partial results to the client with ActionCable or server-sent events for better user experience when inferences take time.
Store embeddings or use external vector stores to power semantic search and retrieval-augmented generation, keeping the retrieval layer separate from core business logic.
Use Rails’ security, logging and testing tools to ensure model calls, data handling and user-facing outputs are auditable and controllable.

Recent Rails improvements (better performance, improved developer ergonomics and deployment tooling) make these patterns easier to run in production. For clients who need to move fast while keeping operational discipline, Rails remains a practical, reliable choice.

Bottom line: at XAVER we pick Rails because it gets teams shipping quickly, integrates smoothly with modern AI workflows, and scales from prototypes to production without forcing architectural rewrites.