// Security by design

How we built NIUJU, an AI photo app, with security by design

Where the photos go, when they are deleted and why we never see a card number: the decisions behind our own AI photo studio.

What this covers

  • The short answer
  • The problem: people hand over photos of themselves
  • Collect only what the photos need
  • The data flow: where the photos go
  • Deletion by design
  • Payments: keep card data out of our systems
  • How the build was run
  • What we would do the same, and what to check in your own build

The short answer

NIUJU is an AI photo studio that XIVU built and runs. We built it with security by design: before writing the features, we decided where photos are stored, who can reach them, when they are deleted and how payments work. Every change that touches personal data, accounts or payments is reviewed before it goes live.

This article walks through those decisions in the order a builder meets them: the problem, the data flow, deletion, payments and the build itself. If you are planning an AI app that handles personal photos, you can use it as a checklist.


The problem: people hand over photos of themselves

People want professional-looking photos for LinkedIn, CVs and social profiles without booking a photographer. On NIUJU they upload up to four photos of themselves, pick a style and get new, studio-style photos back.

That makes trust part of the product. A customer is about to give a company they have never heard of pictures of their own face. If the answer to "what happens to my photos?" is vague, long or hidden in legal text, they have every reason to stop right there. So the data handling had to be clear, short and true, and the product had to be built so that those short answers stay true.

We were also careful about what NIUJU is not. It creates new photos from the ones you upload. It does not recognise, identify or match faces, and we do not describe it as if it did.


Collect only what the photos need

The safest data is data you never collect. The NIUJU privacy policy names strict data minimisation as one of its measures: only the photographs needed to create the images, plus the account details needed to run an account and sell credits.

The upload is limited to four photos, one for each kind of shot the studio uses. A fixed, small input is easier to protect, easier to delete and easier to explain than an open folder of everything a user might send.


The data flow: where the photos go

Accounts, uploaded photos and finished images are stored on EU servers in Ireland. Data is encrypted in transit and at rest, and access is limited by user-scoped access controls, so one account cannot reach another account's photos.

One step works differently, and we say so up front. To create the images, the photos travel over an encrypted connection to our contracted AI provider. The provider runs its image model on a global network, so this step can take place outside the EU, mainly in the US. It is covered by a data processing agreement and the EU Standard Contractual Clauses. Our AI provider does not use the photos to train its models and does not keep them after the images are made.

We chose to state this plainly instead of hiding it behind a vague line about EU hosting. Storage in the EU is true, and so is the outside-EU step. A buyer who later finds the second fact on their own stops trusting the first. The full details, including every service provider, are in the NIUJU privacy policy.

The four supplier questions from our secure SDLC checklist are worth asking of every outside service an AI app uses: where does the data go, who can access it, what happens if they are breached, and how do we get out again?


Deletion by design

Deletion is a scheduled job, not a promise. Uploaded photos are deleted automatically 7 days after upload. Finished images are kept for up to 7 days so the customer can download them, then they are deleted too.

Customers do not have to wait. They can delete their photos and images earlier at any time, and deleting the account removes them immediately. Deleted data can stay in the daily encrypted backups for up to 7 more days, then it is purged. We state that backup window instead of pretending deletion is instant everywhere.

A fixed retention period decided on day one costs one scheduled job. Deciding it after launch means first finding every copy. It also turns into a sentence a customer can understand and hold us to: your photos are gone 7 days after upload.


Payments: keep card data out of our systems

Payments run through Stripe. Full card details are handled by Stripe, and we never store card data. Data we never hold cannot leak from our systems, and the hardest part of payment security stays with a provider that specialises in it.

The business model helps here too. NIUJU sells one-time credit packs from €29 incl. VAT, and gift cards. There are no subscriptions, so there is no recurring billing to run or to secure. The current packs are on the NIUJU pricing page.


How the build was run

NIUJU was built solo by Chan Vu Luu, with AI coding agents doing the typing. The agents write the code; product decisions, security and privacy trade-offs and the final release stay with a person. The rules and decisions are written down in the project's instruction files, so every agent session starts with them.

Changes that touch personal data, accounts or payments pass security, privacy and payment reviews before they go live, and the agent that reviews a change is never the one that wrote it. A data protection impact assessment was completed, and every processor that handles the photos is bound by contract.

We are just as precise about what we do not claim. NIUJU holds no ISO 27001 or GDPR certification. We built it with the GDPR in mind and aligned with ISO 27001, and we say exactly that.


What we would do the same, and what to check in your own build

We would make the same core decisions again: storage in the EU with the outside-EU step stated plainly, deletion as a scheduled job with a short, fixed period, a small and fixed upload, card data kept out of our systems, and a review before release for every change that touches personal data, accounts or payments.

If you are building your own AI app, check the AI step first. It is the part most likely to send data to another company and another country, so its contract, training terms and location decide what you can honestly promise. Then write your deletion rule before your first upload feature, and write your privacy answers before your marketing copy, so the copy can only say what the product does.

The NIUJU case study lists every decision in one place, and the trust page has the same facts in two minutes of reading. If you want a product built this way, start with the secure SDLC article or get in touch.


Related

NIUJU case studySecure LaunchSecurity Partner for your project

Have something to ship?

FREE INTRO CALL · FIXED QUOTE WITHIN 2 WORKING DAYS OF THE CALL

Start a project