eyeq.studio — build journal

We were selling the wrong thing

What we set out to do. Review where the business had got to. We had spent months building a service that made websites for small businesses in Malta — different price tiers, different design treatments depending on the trade you were in.

What we did. We stopped. Instead of a website business that used a bit of AI, we made it an AI business that happens to give you a website. The website becomes the shopfront; the real product is a set of AI tools sitting behind it that do the boring daily jobs — VAT paperwork, reminders, customer messages, quotes, special offers.

What went wrong. Nothing broke, but a lot of work went in the bin. Months of pricing, page designs and category-specific templates stopped being relevant in an afternoon.

What we learned. The trade a business is in stops being a design decision and becomes a filter — it changes which options we show, not what we build. That one sentence removed an enormous amount of duplicated work.

What's next. Rewrite everything that describes the old product, before it gets quoted back at us.

Saying in one line what the business is

What we set out to do. Settle how eyeq.studio describes itself, and how it differs from the consulting side.

What we did. Landed on the distinction: the consulting practice advises what's possible; the studio uses AI to make a business run better. Then a three-line lockup — what it is, what it does for you, and the family promise underneath.

We put a hold on using the middle line publicly, because it implies a piece of the product exists that hasn't been built yet.

What went wrong. While updating the record we found two entries that had been wrong for weeks. A design switch window that was cancelled on 22 July was still written down as live. A trade category parked on 20 July was still listed as available. Both had sat there, quietly wrong, ready to be quoted at a customer.

What we learned. A decision made in conversation and not written down immediately isn't a decision, it's a memory. We now record how many days each stale entry sat uncorrected, because the number is uncomfortable and that's the point.

What's next. Cascade the change into the pages and documents that repeat it.

Eleven things wrong with a form we thought was finished

What we set out to do. Test the questionnaire that asks a business owner about their trade, their colours and their photos, then generates three website designs for them to pick from.

What we did. Sat with it on a real screen and broke it. Then fixed eleven separate faults one at a time, each one deployed and re-tested before moving to the next.

What went wrong. Almost everything, in small ways. Six screens where tapping an option did nothing. A brand with a black-and-white logo came back with pink and yellow suggestions, because the colour reader treated "almost no colour" as an error and invented some. A button labelled "Layout's off" broke on its own apostrophe. A "none of these look like me" option was a dead end with nowhere to go.

What we learned. The apostrophe bug is the one to remember — a perfectly ordinary punctuation mark inside a label silently broke the button. And the colour reader taught us that a system which refuses to say "there isn't much here" will make something up instead.

What's next. The design previews are text-only and feel flat. Add real images.

Nowhere to look at the results

What we set out to do. We had a test running and people filling it in, and no sensible place to read what came back.

What we did. Built two things. A review screen where every submission appears with the three designs it produced, a traffic-light marker, and a "done" toggle. And above it, a hub page — a front door listing every test we're running, how many people have submitted, and how far through the reviewing we are.

We also replaced the placeholder photos in the design previews with forty properly chosen images, five interiors and five team shots for each of four trades, checked one by one.

What went wrong. The review screen was first built in the wrong folder. Moving it mattered more than it sounds: the reviewing marks are stored in the browser, and browsers refuse to share that storage across different web addresses. Wrong address, and every mark disappears.

What we learned. Build the place you read results at the same time as the thing that produces them. Otherwise the results pile up unread and the test is worthless.

What's next. A second test bed — receipts and VAT.

The submission that never arrived

What we set out to do. A tester filled in the questionnaire and got an error. Find out why.

What we did. Read the form's code, checked the receiving end, and pulled the log of everything that had arrived that morning.

What went wrong. Nothing arrived. Not a failure, not a rejection — the submission never reached us at all. That narrowed it down: the message was too big to leave her browser.

The photos were being shrunk before sending. But two things weren't: the logo file, sent exactly as uploaded, and any menu or price list, which can be a large document. Together they can add several megabytes to something already heavy.

What we learned. An error that says "failed to send" and an error that says "we received it and rejected it" are completely different problems, and knowing which one you have removes most of the guesswork. Also: our form had no size limit and no photo count limit at all.

What's next. Shrink the logo, send only the name of large documents rather than the document, and record the actual size when a send fails.

Can a computer understand Maltese?

What we set out to do. Every one of our tools is designed to be talked to rather than typed into. Our customers speak Maltese, or Maltese and English mixed in the same sentence. So: can any speech-to-text service actually cope with that?

What we did. Checked the published accuracy figures for every major provider against Maltese, rather than trusting marketing pages.

What went wrong. The results were worse than expected. Two of the four biggest names in speech recognition are effectively useless on Maltese — one gets roughly nineteen words wrong in twenty, another gets almost every word wrong. A third puts Maltese in its lowest accuracy band.

What we learned. One provider rates Maltese in its high-accuracy tier and handles mid-sentence language switching without being told, which is exactly what our customers do. We're building against that one. A second provider will be run later over the same recordings as a control, so if the results are poor we can tell whether it's the vendor, the language, or our recordings at fault.

We also locked a product decision: voice and typing are parallel options, always. If voice fails, voice gets delayed — the feature doesn't die.

What's next. Write the paragraph testers will read aloud.

Marking the machine's homework

What we set out to do. Build the screen where a human listens to a recording, corrects the transcript, and produces a score for how wrong the machine was.

What we did. Built it. It plays the clip, shows what the machine heard, lets a person fix it, and works out the error rate. Corrections are saved back automatically.

What went wrong. Nothing broke, but two rules had to be argued out. First, the score is hidden until there are at least ten clips, because two recordings is not a measurement and a number on screen invites people to believe it. Second — and this is the important one — the person correcting must listen to the audio, not read the transcript and tidy it up. If you correct against the text, you are grading the machine against its own answer, and the whole exercise becomes meaningless.

What we learned. Where the ground truth comes from matters more than how you measure against it. Get that wrong and your accuracy figure is decorative.

What's next. Prove the save actually writes back, then add a second set of columns so the same clips can be run twice with different settings.

Hearing, understanding, learning — three different problems

What we set out to do. Get the voice experiment properly structured, and build a controlled version of the test where we know exactly what was said.

What we did. Split the work into three stages that never get mixed up again. Hearing — turning sound into text. Understanding — turning that text into a structured list of things to do. Learning — feeding corrections back so it improves.

Then built a lab form with two questions: a fixed Maltese-English paragraph read aloud, where we know every word in advance and can score automatically; and an open question about what you ate today and what it cost, which is where real speech gets messy.

What went wrong. Getting the paragraph right took several passes. Words were swapped, a money amount was reworded, and the spoken form of a number had to be frozen so scoring couldn't be argued with later.

What we learned. The controlled recordings came back far clearer than the ones captured in a working café. That gap is itself a finding: background noise, not the language, may be the bigger enemy.

What's next. Register it on the hub and check the numbers appear.

Can a machine read a Maltese receipt?

What we set out to do. Open a second experiment. Take a photo of a real Maltese receipt or a till's end-of-day printout, and find out whether AI can read it accurately enough to be trusted with someone's VAT.

What we did. Built the whole chain in a day: a form testers can upload photos to, the AI reading step, a spreadsheet to hold every answer, and a review screen. Then designed what the AI is actually asked to extract, working from ten genuine Maltese receipts rather than from imagination.

What went wrong. The receipts fought back. The word "net" appears three times on one till printout meaning three different things, and only one of them means "before VAT". The letter codes that mark tax rates — F, R, M, E — have no national standard, so the same letter means different things on different tills. And plenty of perfectly legal Maltese receipts print no VAT figure at all.

What we learned. Never guess a tax rate from a letter. If the paper doesn't say it, the honest answer is "the receipt doesn't say", not a calculation.

What's next. The reading step is rejecting our requests within a second. Find out why.

One wrong word in a password field

What we set out to do. Find out why the receipt-reading step was rejecting everything within a second of starting.

What we did. Added a column to the spreadsheet that records exactly what the AI service said when it refused. It said the key was invalid. The key was fine — it was being handed over in the wrong format, using the label one service expects instead of the label this one expects. One word, in one settings box.

Then rebuilt the tester's review screen. It had been a flat wall of seventy-four fields, which is unreadable. It became a numbered list of lines, each opening into a small drawer showing only what matters.

What went wrong. A second fault took most of the session. On a long receipt the AI was spending its entire allowance on thinking and returning nothing at all. We turned the thinking off for this job and doubled the allowance.

What we learned. When something fails instantly and silently, the first job is to make it tell you what it said. Guessing costs more than instrumenting.

What's next. Score the results against a hand-checked answer key.

Designing the screen where a human checks the machine

What we set out to do. Design how a shop owner confirms or corrects what the AI read off their receipt — from a hand-drawn sketch.

What we did. Built an interactive mockup and argued it into shape. Each line collapses to a number, a description, an amount, a tick and a cross. Open it and there are exactly four things you can edit. Save per line; save all at the bottom.

What went wrong. Several instincts turned out to be wrong when looked at properly. "Cannot tell" was removed entirely — if the photo is illegible the answer is take another photo, not guess, because a guess poisons the answer key we're grading everything against. Totals never recalculate: they're printed on the paper and the paper is the authority, so if the lines don't add up we show the discrepancy rather than quietly fixing it.

What we learned. All of this went into the written record marked NOT BUILT, so nobody reading it later mistakes a mockup for a working screen.

What's next. Actually build it.

Shipping the checking screen, and three bugs that looked like nothing

What we set out to do. Build the screen designed in the last session and get it live.

What we did. Built and shipped it across several small deployments.

What went wrong. Three bugs, each trivial and each expensive. A styling rule meant to hide one thing hid every tick button on the page. A price stored as "10.5" and displayed as "10.50" made the system think the user had edited it, so untouched lines were recorded as corrections. And the tool we use to make surgical edits treats the search text as a pattern rather than plain text, so ordinary programming symbols broke it.

We also reversed a decision from the previous session. Retaking a photo now starts a completely fresh record rather than reusing the old one, because the way the pieces are wired makes reusing it unsafe.

What we learned. Two ways of writing the same number is a bug waiting to happen. And we'd spent too long verifying and not enough building — noted at the time and corrected.

What's next. Automate the runs so we can test many documents at once.

Testing one receipt at a time was never going to work

What we set out to do. Stop uploading documents by hand. Build something that fires a whole folder of receipts through the reader automatically, several times each, so we can see whether it gives the same answer twice.

What we did. Built the automatic runner and two helper tools that read the results back. Assembled eight confirmed documents and completed twenty-five runs. Scored half of them against a hand-checked answer key.

What went wrong. Halfway through, everything stopped. Our automation account had used up its monthly allowance, which silently pauses every process — including live ones serving actual clients. No warning, no error. Requests are accepted and simply never run.

What we learned. That silent pause is now the first thing we check before debugging anything. One free call answers it.

Two product rules also came out of the scoring. Never calculate VAT from a tax-code letter. And never treat the letters "EXP" as a marker for anything, because they collide with card expiry dates that appear on the very same receipts.

What's next. Finish scoring the remaining four documents.

The AI wasn't making things up — it was filing them wrong

What we set out to do. Finish scoring all eight test documents and decide how the next stage works.

What we did. Completed the scoring. Every printed total was read correctly, in every run, on every document.

What went wrong. The errors were all of one type, and it wasn't the type everyone fears. The AI wasn't inventing numbers. It was reading them correctly and putting them in the wrong box. A real figure, accurately read, filed under the wrong heading.

We also disproved our own theory. We'd assumed long documents would be less reliable. They aren't — what predicts errors is how many separate judgements a document forces, not how long it is.

What we learned. "Hallucination" is the wrong worry for this job. Misfiling is the real one, and it's a different fix: clearer instructions about which box is which, not a better model.

We also inverted a governance rule. Truth now lives in the reference files, always. The task tracker is a dated history of what was decided when, not the authority.

What's next. Build the rules layer that sorts documents into piles.

Three piles, and no AI involved

What we set out to do. Build the part that takes what the AI read and decides what to do with it — deliberately without using AI.

What we did. Wrote a plain rulebook. Every document lands in one of three piles: VAT we can read, the accountant needs to see this, or this isn't a VAT document. Same input, same output, every time, and you can point at the exact line that produced the answer.

Added one rule that turned out to be essential: a photo containing more than one document is rejected before anything else runs. That came from a real test document — one photograph containing four separate card slips from four different shops.

What went wrong. A full sweep of the results showed five of seven usable documents ask the customer a question. Seventy-one percent. Our target was twenty-five. An app that interrogates you about nearly every receipt gets deleted in a fortnight.

What we learned. The judgement step must not learn or drift. If it changes its own mind you lose the ability to explain any answer you've ever given.

What's next. Decide what to do about the questions.

Cutting eight paper rolls out of five photographs

What we set out to do. Deploy the multi-document rejection rule, and process a batch of new test material photographed by a colleague.

What we did. Deployed the rule. Then dealt with the photographs: several long till rolls laid out together in one frame, curling, overlapping, at angles.

We built something that cuts around each roll's own outline rather than drawing a box around it, and a method for joining three overlapping photos of one long roll into a single strip. Tested it on every roll: fifteen of sixteen real joins accepted, all eight deliberately fake joins refused, no wrong joins at all.

What went wrong. The rejection rule had to be rebuilt from scratch. It had existed only in the previous session's working space, which is wiped between sessions, and it had never been saved anywhere permanent.

What we learned. A written total can settle an unreadable digit. On a handwritten invoice, the arithmetic disambiguated a figure the AI genuinely could not read.

What's next. Decide what to do about the question-fatigue problem.

The pop-up stays, and here is why

What we set out to do. Settle the question that had blocked us for a week: five out of seven receipts trigger a question to the customer. Too many. What do we do?

What we did. Kept the pop-up. Rejected three softer alternatives — a quiet label, showing it once then going silent, a summary at the end of the batch.

The reason came from a correction made mid-session. This module isn't only a VAT tracker; it also produces a running figure for money in and money out. That reframes everything. A receipt with no VAT on it isn't a failure to be apologised for — it's news. It still counts as an expense.

What went wrong. Two beliefs turned out to be wrong. Our written record said six documents went to the accountant pile; the real number is five. And we had been saying the sales side was tested and ready — it wasn't. Zero of eight till printouts had ever been through the reader. That belief traced back to a July design note predicting good accuracy, not a measured result.

What we learned. A prediction written down in July reads exactly like a result by August.

What's next. Actually test the sales side.

Testing the sales side for the first time

What we set out to do. Run eight end-of-day till printouts through the reader, three times each, and score them properly.

What we did. Twenty-four runs. Money was perfect — every VAT total and every gross figure correct on every run.

What went wrong. Dates were the weak point, twelve correct out of twenty. Two separate diseases. Some rolls consistently picked up a date from 2014 — the day the till was first set up, printed near the top of every roll ever since. Others gave the right answer, then the wrong one, then the right one again on the identical file.

One document returned no date at all — and that was correct. The date physically runs off the edge of the photograph. The machine didn't fail; it declined to invent something.

What we learned. Five date rules, in order: ignore anything under a "non fiscal" heading, ignore the setup date, take the latest of what's left, ask if two are close, and if none survive, insist on a new photo. That scores eight out of eight with no questions asked.

Also: printouts saved as documents rather than photographs cannot get through the system at all.

What's next. Review all the modules and build a proper plan.

Deciding what things cost, and one rule we will not break

What we set out to do. Clear five open commercial decisions that had been blocking other work.

What we did. Rotated two security keys. Settled pricing across the whole product. Sent enquiries to four government bodies about grant eligibility, describing the service by outcome only.

We also checked a naming convention we'd been designing around for weeks and found it had never existed and — more importantly — was never buildable. The platform generates those field names itself with random endings, so the shape we'd assumed was impossible from the start.

What went wrong. A pricing idea we had already rejected got re-proposed the same day. It was rejected again for the same reason: it would have sold a cut-down version that couldn't handle most Maltese receipts, because most of them print no VAT at all.

What we learned. The standing rule that came out of it: charge more for a deeper service, never for a working version of the basic thing. And never dress up complexity to justify a price — show the real complexity instead.

What's next. Redesign the free diagnostic, which the pricing change has broken.

No rigs, no workarounds

What we set out to do. Settle whether any paid part of the service carries a free trial, and test the reader against a completely different till.

What we did. Decided: no free trials. The reasoning is that the trial already exists — the setup fee includes two working tools running on the client's own data from day one. Every reference to the old trial regime was retired but left visible with a superseded tag, rather than deleted.

Then tested eleven end-of-day printouts from a second business with a completely different till.

What went wrong. The first two runs died writing nothing at all. The AI returned the shop's name as a small bundle of details — name, address, phone — instead of a single piece of text, and the spreadsheet refused it. One badly shaped field destroyed all fifty columns.

The obvious fix was to flatten it at the spreadsheet. That was rejected on the spot, and it produced the most important rule of the project so far.

What we learned. There is one chain. The test system *is* the product being built. Every fix goes in as the real fix, in the place the finished product will have it — never a patch that exists only in testing. Otherwise the test passes, the real defect stays, and the testing was wasted.

What's next. Build the missing stage properly.

A score that could go down when we did something good

What we set out to do. Fix the free diagnostic. It scored a business out of a hundred, and the pricing change had broken the logic underneath it.

What we did. Redesigned it from scratch around two separate things that never merge. A percentage, showing progress through the level you're on. And a level — Bronze, Silver, Gold and up — that once earned is never lost.

What went wrong. The flaw in the old design was serious. Every time we shipped a new tool, the total number of things a business could be doing grew — so an existing client's score would drop, through no fault of their own. We'd have been punishing paying customers for our own progress.

What we learned. A percentage can absorb a moving target. A name cannot. So the level ratchets upward only, and the percentage does the moving.

We also made levels fill on *use*, not purchase — which means someone can pay and see the number stay still that day. The screen must say plainly what they've unlocked and what fills it, or the purchase feels broken.

What's next. Nothing is built. There's no record of client activity anywhere yet.

The gap between reading a receipt and saving it

What we set out to do. We had a piece of code that sorts receipts into three piles: ones where we can read the VAT, ones the accountant needs to look at, and ones that aren't VAT documents at all. It had been written weeks earlier, it passed every test, and it was connected to nothing. The job was to plug it in.

What we did. Widened the results sheet, added six new columns, and rewired the pipeline so every document now goes: read it, sort it, save it. Then ran eleven till closures from a second business — a hair salon with a completely different till to the one we'd tested on.

What went wrong. Five of the eleven vanished. Not failed — vanished. No error, no row, nothing. They stopped halfway and left no trace. We also found that five date rules we'd agreed days earlier had never actually been written into the code.

What we learned. Money reading was perfect — six out of six on a till we'd never seen. But we discovered we were flying blind: when something breaks in the middle, we have no way of seeing what happened. That became the next job, ahead of everything else.

What's next. Build the black box recorder before running anything else.

Designing the black box recorder

What we set out to do. Close the hole that let five documents disappear without trace.

What we did. Designed a recorder that sits between the AI and the step that failed, and writes down what the AI actually said before anything tries to interpret it. It stores to a private, admin-only table — not a spreadsheet — because that matches how the finished product will work.

Ten categories of problem, only one of which is "fine, still processing". Everything else is flagged for review. Crucially, it's wired so that if the recorder itself fails, it cannot take the main job down with it.

What went wrong. Nothing. Two alternatives were considered and rejected: attaching an error handler to the failing step, which only fires on total failure and would stay blind to the near-misses; and writing to a spreadsheet, which doesn't match the real product.

What we learned. Recording only failures is not enough. A job that nearly ran out of room looks identical to a healthy one, right up until the day it doesn't. You need the record on the good runs too.

We also rebuilt the plan, adding the completed history so progress is visible rather than assumed.

What's next. Deploy it.

Two systems that spell things differently

What we set out to do. Deploy the black box recorder designed in the previous session.

What we did. Created the private table it writes to, building it through code rather than clicking through an editor, with all its fields and admin-only access locked from the start.

What went wrong. The code and the table disagreed about how to spell field names — one uses underscores between words, the other runs them together with capitals. Small, but it would have failed on every single write.

Two ways out: rebuild the table to match the code, or write a translator between them. We chose the translator, because the platform has no rename function — changing a field name means deleting it and losing everything stored in it. That makes the table's spelling effectively permanent once real data exists.

What we learned. The translator does more than translate. It refuses loudly if it meets a field it doesn't recognise, rather than dropping it silently. And there's a test that fails if the two sides ever drift apart, so a future change can't quietly break it.

What's next. Deploy both pieces to the repository.

One giant instruction manual nobody could read

What we set out to do. Fix how the AI remembers the business. Everything it knew about EyeQ lived in one enormous file. Every time it needed one fact it had to carry the whole thing.

What we did. Split it into seven smaller books, each with a clear job — brand rules, the studio product, page design, active research, legal, and so on. Then a separate book for each platform we use, so the AI reads the instructions for the tool it's about to touch before it touches it.

We also wrote down seven working rules and made them permanent: change the smallest thing that works, never overwrite a file when you can edit a line, check before you claim, ask only when a human genuinely has to click something.

What went wrong. Nothing this session. The temptation was to split further than necessary just because it looked tidier.

What we learned. Only split something when it has a genuinely different trigger AND it has grown big enough to justify the cross-referencing. Tidiness on its own is not a reason.

What's next. Use it and see what falls out.

Looking for something we were sure we had written down

What we set out to do. Find everything we'd recorded about the module that tracks recurring commitments — equipment servicing, renewals, things that come round every year.

What we did. Searched the project files, past sessions, the reference books and the task tracker. Found it: a module that pulls every recurring commitment, business and personal, into one place with a month, quarter and year view, reminders a month ahead, and a view of the money needed to cover each one.

What went wrong. Two gaps. The word "warranty" appears nowhere — we'd remembered a feature that had never actually been specified. And the module's entire specification exists in exactly one place: a single task. None of the reference books contain more than its name.

What we learned. A thing described in one place only is a single point of failure. And "I'm sure we decided that" is not evidence — twice now, a confidently remembered feature has turned out never to have been written down.

What's next. Nothing immediately. Noted for when that module's turn comes.

Every session had been opening the wrong file

What we set out to do. Audit every reference document after the pivot and clear out anything describing the old product.

What we did. Found the root cause of a problem that had been producing wrong answers for weeks. The routine that loads context at the start of every session had a list of which documents to read — and the master record, the one file that holds every locked decision, was not on it. Every session had been opening a large file that was comprehensively out of date, and never opening the correct one.

Rebuilt the main product document from just under fifteen hundred lines to under four hundred. Froze the pre-pivot material in a separate archive marked never-authoritative. Deleted two documents and six stale project files, checking first that nothing unique was lost.

What went wrong. Three mistakes, all caught. A document was invented and written into files as though it existed. The time was estimated rather than checked and drifted forty minutes. And a save was reported as failed based on a check that cannot detect recent saves.

What we learned. Check the clock, never infer it. And before deleting anything, confirm its unique content survives elsewhere.

What's next. Settle the free trial question.

Four places to look and no single truth

What we set out to do. Answer a plain question: where does the business get run from? Is the website builder also the control panel, or does that need to be something separate?

What we did. Separated the two properly. The website platform keeps what it's genuinely good at — the public site, member logins, the client's own portal, bookings. Everything else needs its own internal console.

The reason is simple: the website platform cannot see the client sites we host elsewhere, the automation platform, the code repository, the spreadsheets or the messaging system. An operator's dashboard that can only see one quarter of the business isn't a dashboard.

What went wrong. Nothing broke, but a bigger problem surfaced. Business data currently lives in four separate places with no single truth. That has to be fixed before any console can be meaningfully built.

What we learned. One door. Everything reads and writes through a single address we control. From today, every decision — every field name, every route, every storage choice — gets made so that it's easy to plug into that door later.

What's next. Nothing scheduled. Planning only. The public site comes first.

Writing down the build while we can still remember it

What we set out to do. Start a journal of the build — plain language, one entry per session — so the team can follow what's happening and why, and so there's honest material for writing about it publicly later.

What we did. Agreed the shape. One file per session. Five plain sections: what we set out to do, what we did, what went wrong, what we learned, what's next. Then a separate block holding a longer written piece, hidden inside markers a machine can find but a reader never sees.

Went back to the pivot on 18 July and wrote up all twenty-nine sessions since.

What went wrong. Two clashes had to be settled. The build plan numbers today's session as its second, while the sessions themselves had been counting from one for the past few days — so the journal counts its own way and names the plan stage in the text instead. And entries are tagged to stage *names*, not numbers, so that when the plan changes the journal bends rather than breaks.

What we learned. Made it a standing rule: if the plan version changes, stop and discuss what it means for the journal before touching a single entry.

What's next. Get the plan and the journal onto a private address.