A web application, built and attacked by the same person.
For founders building something with users, logins and data — a portal, a marketplace, an internal tool, a SaaS product — who would rather pay one person to do the whole thing properly.
You have users who log in and data they trust you with, and you'd rather pay one person who can design, build and test the thing than coordinate a designer, a developer and — usually never — a security tester.
If what you need is a marketing site or a landing page rather than an application, that's a separate, smaller offer with its own price: see Websites.
how it goes
Four steps, in order.
Discovery, design, development and the attack — with security in every one of those, not bolted on at the end.
001
Discovery and scope
What it does, who uses it, and what it must never leak.
before a line is written
002
Design and build
Auth, dashboards, admin, database — built once, properly.
drawn for this app, not a theme
003
The attack
The person who built it spends the last week breaking it.
the week that never gets cut
004
Launch and after
You own the code, the domain and every key on day one.
on your accounts, in your name
what a build includes
Every build, at every price, goes through all of this.
Discovery, design, development — with security in every one of those, not bolted on at the end.
01
Discovery and planning
Requirement sessions, user flows, architecture and design direction before anything is coded.
02
Design
Custom, responsive UI — desktop and mobile — in a visual system that fits your brand. No templates.
03
Development
Logins, profiles and dashboards, the database behind them, and an admin area for you — built on a current, widely used stack (Next.js, Supabase, Vercel) that any developer can pick up after me.
04
Security review, before launch
In the final week I run the same pre-launch review I sell standalone for $522 against what I built. Findings in writing, fixed before launch.
05
After launch
5 working days to review and accept, then 30 days of bug fixes on anything in scope. New features are quoted separately, in writing.
security, during the build
The part nobody else at this price does.
This is what changes when the person building it knows he'll be the one attacking it in week six.
01
Access control designed on paper before the first screen
Who can see and do what — and what happens when they try what they shouldn't.
02
Prices, permissions and scores decided by the server
Never by the browser — so nobody can change what they pay or what they can see by editing the page.
03
No passwords or keys in the code, ever
Checked across the whole history of the code, with an automatic check that keeps it that way.
04
The browser-level protections this site carries, from the first deployment
Run any header checker against alythen.com to see the set.
05
Third-party code checked before launch
Every library the app depends on is checked for known holes, and the holes are closed before anything goes live.
06
Every place the app accepts input, reviewed against the ten most common web attacks
The ones behind most real breaches: people reading data that isn't theirs, injected scripts, hijacked sessions.
what you receive
A finding, as it arrives.
Every finding in a report says what the issue is, what an attacker gains, exactly how to reproduce it, and how to fix it — ranked by real-world impact, never a scanner result passed through. This one is from the public sample; the whole 12-page report is linked under it.
IDOR on order endpoint exposes any customer's orders
Order API · CWE-639 · OWASP API1:2023
What the issue is
GET /v2/orders/{orderId} verifies that the caller is authenticated but never checks that the order belongs to them. Order IDs are sequential integers, so the entire order table can be walked by incrementing a number.
What an attacker gains
Any authenticated customer can read every order in the system: line items, totals, delivery addresses, phone numbers and email addresses. For a retailer this is a personal-data breach affecting the whole customer base, reachable from a free signup.
Reproduction
# authenticated as customer A (own order)
GET /v2/orders/10442 → 200 OK // expected
# same session, another customer's order
GET /v2/orders/10441 → 200 OK
{"orderId":10441,"customer":{"name":"[REDACTED]", …
A short script walking IDs 10000–10500 returned 500 of 501 records. Enumeration was stopped at that point and no data was retained; the redactions above are applied at capture.
How to fix it
Enforce ownership server-side on every object access — the query itself should be scoped to the caller, not filtered afterwards. Replace sequential identifiers with UUIDs so that enumeration is not trivially possible even if a check is missed in future.
-- scope the query, do not check after fetching
SELECT * FROM orders WHERE id = $1 AND customer_id = $2;
Add an automated test asserting that customer A receives 404 for customer B's order. This class of bug returns whenever a new endpoint is added, so the guard needs to be a test, not a code review habit.
Sample report · fictional target · every finding, payload and identifier in it is synthetic. Real reports go to the client and nowhere else.
timeline and price — fixed, agreed in writing before work starts
1,5700
USD, from · build with pre-launch review · ₹1,50,000
2,6100
USD, from · build with a full penetration test · ₹2,50,000
40
to 8 weeks — the typical build timeline
30 days0 days
of in-scope bug fixes after acceptance
Four to eight weeks, depending on scope and how quickly you can give feedback. Payment is 40% to start, 30% mid-way, 30% at launch.
builds with a full penetration test
When the review isn't enough.
Payments, health data, personal information at scale, an enterprise customer or an investor's security questionnaire: builds from $2,610 include a full penetration test of the application and its API in the final two weeks — findings ranked by severity with reproduction steps, a report in the public sample format, and one retest of the fixes within 30 days.
why the floor is where it is
Below $1,570, the testing is what gets cut.
A build is four to eight weeks of one person's full attention, and one of those weeks is spent trying to break what I made. Below that number, that week is the one that goes — and then I'm selling what everyone else sells.
What you get: the code in an account you own, the application running on hosting in your name, the written findings from the review, and a handover — written notes plus a call — on how it's built and how to run it.
before you start a build
Questions people actually ask.
What does a build cost?+
From $1,570 (₹1,50,000) with the pre-launch security review included, and from $2,610 (₹2,50,000) with a full penetration test. Fixed price, agreed in writing before work starts. Payment is 40% to start, 30% mid-way, 30% at launch.
How long does a build take?+
4–8 weeks, depending on scope and how quickly you can give feedback. One of those weeks is spent attacking what I built.
Who owns the code and the accounts?+
You do. The application runs on hosting accounts in your name, on your domain, and the code lives in an account you own. If we part ways, everything stays with you.
What happens after launch?+
5 working days to review and accept, then 30 days of bug fixes on anything within the agreed scope. New features are quoted separately, in writing.
Will you build a marketing site?+
Yes — as its own offer, not at the app price. A marketing site or landing page is from ₹75,000 (about $900), 3–4 weeks, with the same pre-launch security review. See Websites.
start a build
Tell me what you're building.
Two lines is enough. I reply within one working day; the first call is free and about fit.
