How we're building FinSight AI: process, payments, security and launch

This is an open record of how FinSight AI is being built: the engineering process, how payments work, what we do for security and privacy and how we're preparing the launch. We wrote it for anyone starting a software company who wants a map of what exists beyond the code — and to show, transparently, how we work.

One caveat before we start: we document practices and processes, not configurations. Infrastructure details, internal addresses, protection rules and exact limits are left out on purpose. More on that at the end.

Where the product is today

FinSight AI is AI-powered financial management software for small and medium-sized businesses. It's in pre-launch: the main modules are ready and in testing, some screens may still change and access starts by invitation.

What already works:

• Finance: entries, accounts payable and receivable, budgets and targets.
• Cash view: projected cash flow with "what if" simulation, a monthly income statement (DRE) and reports in PDF and by email.
• Billing: payment links, Pix and boleto (Brazilian bank slip), with reminder sequences by email and WhatsApp.
• Bank and tax: reconciliation by bank statement (OFX) or Open Finance, and service invoice (NFS-e) issuance.
• AI: a Virtual CFO that analyzes the numbers and a Copilot that carries out tasks — always with confirmation.
• Integrations: a public API, webhooks and an MCP server to connect other tools and AI assistants.
• Team: multiple people per company, with roles and permissions, and an interface in Portuguese and English.

Still in the queue: custom roles per company, fuller error monitoring and end-to-end tests of every payment method in production.

How we work

Tests before every release

Every change goes through type checking and an automated test suite that now has close to a thousand tests. They cover everything from accounts and reports to the points that matter most in a financial product: isolation between companies (one company never sees another's data), payments that must never be counted twice and the privacy rules.

The AI has its own test batteries: one that checks whether the Copilot picks the right action for each request, and another that runs real conversations end to end.

From code to production

• Continuous integration: type checking, tests, build and a scan for secrets accidentally left in the code that ships to the browser.
• Two environments: staging, to validate, and production, for customers.
• Numbered versions: only a tagged version (v1.2.3) goes to production, with a health check after the deploy and release notes.
• Configuration that defends itself: the server refuses to start in production if a critical setting is weak or missing.
• Full local environment: a local database and a demo company with more than a year of fictional data, so we can test without touching real data.

AI agents as part of the team

We use AI agents to speed up development, several at once, each one in an isolated copy of the code. What they write goes through the same tests, the same review and the same release process as any other change.

What Pix is, in a few words

Pix is the instant payment system created by the Central Bank of Brazil. Money arrives in seconds, at any time, every day, and the payer only needs a key (tax ID, email, phone number or a random key) or a QR code — which also comes in a "copy and paste" version.

Pix Automático is the recurring version: the customer authorizes once in their bank app and the following charges (monthly fees, subscriptions) are debited automatically, with no need to pay a Pix every month. For subscription businesses, that cuts late and forgotten payments.

How payments work in FinSight

There are two flows, and separating them was one of the first decisions.

1. The platform billing FinSight subscribers. Plans with recurring card payments, Pix Automático and one-off AI credit packs, processed by regulated payment providers.

2. Businesses billing their own customers. Each business connects the account it contracts directly with a payment provider (there are several options) and charges by link, Pix or boleto. FinSight never holds the money: it goes straight into the business's account. That simplifies regulation and reduces risk for everyone.

The life cycle of a charge:

1. The charge is created and sent to the customer.
2. When the payment happens, the provider notifies the system.
3. The system doesn't rely on the notification alone: it checks with the provider again to confirm the real status.
4. The payment is recorded idempotently — the same payment is never counted twice, even if the notification arrives more than once.
5. The revenue lands in the books already reconciled, and the service invoice can be issued automatically.

As a safety net, the system also periodically checks pending charges in case a notification gets lost along the way. Bank reconciliation closes the loop: the statement comes in via Open Finance or an OFX file and is compared with what was recorded.

AI with a handbrake

• The Virtual CFO analyzes the numbers at the frequency the business chooses and produces alerts, a diagnosis and an action plan — using aggregated metrics.
• The Copilot answers questions and carries out tasks: record an expense, create a charge, generate a report.

The rules that make this safe:

• Reading is immediate; changing requires confirmation. Every action that changes data becomes an editable proposal, with "Confirm" or "Discard".
• Permissions are checked again on confirmation. The AI never grants access to anything the person wouldn't have on their own.
• Whatever the AI writes is treated as data, never as authorization.
• Personal data is masked (tax IDs, email, phone, card) before any text goes to the model.
• Usage works on credits, refunded automatically when a call fails.

Legal and LGPD

For anyone starting out, this was the part with the most items that don't show up in the code:

• A formal company (in our case, a limited company under Brazil's simplified tax regime), with an accountant from day one and attention to the service invoice rules.
• Trademark: registration with INPI (Brazil's trademark office) is planned.
• Public Terms of Use and Privacy Policy, written based on the LGPD (Brazil's data protection law), the Consumer Protection Code, the e-commerce decree and Brazil's Internet Civil Framework.
• Acceptance with proof: acceptance is recorded with version and date. If the text changes, the version goes up and everyone accepts again.
• Clear roles: the customer business is the controller of the data it enters; the platform acts as the processor.
• Data subject rights inside the product: export all data and delete the account right in the app, with a data protection officer (DPO) channel and a response deadline.
• Defined retention: each type of data has a retention period, and backups are overwritten in cycles.
• Cookies: only the essential ones by default; usage analytics only with consent.

Still on the checklist: a final legal review, a data processing agreement (DPA), a record of processing activities and a formal incident response plan.

Security

What we do, in general terms:

• Connections always over HTTPS and passwords stored with a strong hash.
• API keys stored only as hashes and integration credentials encrypted.
• Isolation between companies tested automatically and role-based access control.
• Attempt limits and lockout after repeated failures.
• Signature verification on payment provider notifications.
• Security headers in the browser.
• An audit trail, with logs that don't store sensitive data.
• Two-step verification required in administrative areas.
• Daily backups with restore tests and an off-server copy.
• Edge protection with Cloudflare (DNS, HTTPS, web application firewall and attack mitigation).

A lesson worth recording: an edge service alone is not enough. It's one layer. Real security comes from several layers at once — at the edge, on the server, in the database and in the code itself.

Infrastructure, from scratch

The minimum to put a SaaS online responsibly:

1. Domain and DNS with edge protection (we use Cloudflare).
2. HTTPS everywhere, renewed automatically.
3. A server with automated, versioned deploys — no manual changes in production.
4. A managed database, with tested daily backups.
5. Professional email with SPF, DKIM and DMARC configured, so messages don't land in spam.
6. Separate transactional email for sign-up, billing and notices.
7. Monitoring of the service and a public status page.

The launch

Already done:

• A product page and a pricing page with a free plan.
• Basic SEO: sitemap, robots.txt, Search Console and private areas kept out of search.
• Usage analytics with consent, tracking sign-ups and purchases.
• An early-access list.
• Email invitations with single-use links and unsubscribe, starting with accounting firms — which serve many small businesses.
• A referral program: accountants pass a coupon on to their clients.
• Promo codes (free months and AI credits).
• A status page and a community.

Prepared, not yet published:

• Google Ads: search themes and negative keywords already mapped.
• Social media: launch posts, images and video ready.

Next steps:

• An end-to-end test with a real business before the general opening.
• Product Hunt and other launch channels under evaluation.
• A defined support channel.
• Recurring revenue (MRR) and churn metrics from the first customer.

Checklist for anyone starting out

• Company: tax ID, accountant, tax regime, service invoices, trademark registration.
• Legal: terms, privacy, recorded and versioned acceptance, LGPD roles, DPO channel, retention periods.
• Engineering: automated tests, continuous integration, staging separate from production, numbered versions, configuration that refuses to start insecure.
• Payments: a regulated provider, verified notifications, idempotent payment recording, periodic checks, bank reconciliation.
• Security: layers (edge, server, database, code), 2FA in administrative areas, tested backups, logs without sensitive data.
• Infrastructure: domain, DNS, HTTPS, email with SPF/DKIM/DMARC, monitoring, status page.
• Launch: landing page, clear pricing, SEO, waitlist, invitations, referrals, paid channels with search terms already researched.

What we don't publish (and why)

Sharing how we work must not make life easier for anyone trying to attack us. That's why this post includes no internal addresses, server names, firewall rules, exact limits, infrastructure vendors beyond what's already public, or names and contact details of team members. No one at Devx will ever ask for your password, verification code or remote access — if someone asks in our name, it isn't us.

Questions about any of these processes? Reach out through the contact page.