Migration continuity
The scope identifies current URLs, content, integrations, redirects, analytics, cutover responsibilities, and rollback conditions.
The anti-agency · Founded February 2026 · Co-founder led
Reduce migration risk before writing production code.
PandaCodeGen helps businesses plan and implement website migrations when URLs, content, integrations, measurement, and operational control matter. The work begins with evidence and a written scope, not an automatic promise that every site needs a rebuild.
You will not be handed to an account manager. The two founders who scope your project are the two engineers who build it, and if the evidence says repairing your current site is the better answer, we will tell you that instead of selling you a rebuild.
Why we exist
We built this for our own business before we sold it to anyone.
In November we met up after a long time. Imran was running Panda Patches on Google Sheets. Orders, production, the team, all of it held together by spreadsheets and habit. Hassan suggested building a proper CRM and moving the storefront onto Next.js so the team could actually work instead of maintaining the tooling.
It worked. And having done it for ourselves, the gap was obvious: plenty of businesses are carrying the same technical debt, paying for it monthly, and being told it is normal. PandaCodeGen started in February 2026 to do that same work for other owners.
Why we do not take referral commissions
Most agencies recommend the tools that pay them. It is the same arrangement as a doctor prescribing the drug whose maker sends him a cheque, and it is why so much advice points at the same expensive stack regardless of the business receiving it.
A live example. Most small businesses sending transactional email are pushed toward the large marketing platforms, billed monthly, priced for companies far larger than them. For a lot of those businesses a service like ZeptoMail covers the same job for a fraction of it. We will tell you that, because we take nothing from either vendor. Check the current pricing yourself before you buy anything, including anything we suggest.
Not every business is Nike. Most owners want the thing to work and the bill to stay small, and that is a legitimate goal rather than a lack of ambition.
Why we hand everything over
Site builders look cheap until you try to leave one. The lock-in is not in the monthly price, it is in what you cannot take with you: the content model, the integrations, the URLs, the years of work that only exist inside their system. By the time you want out, moving feels impossible, which is exactly the position the pricing was designed to create.
So the source code, design files, content models, documentation and production accounts are yours on handover, the price is fixed before work starts, and there is no monthly licence to keep your own site running. Those are terms in the written agreement rather than promises on a page, because we have watched what happens to people who only had the promise.
Company facts
The people accountable for the work
Two co-founders scope the project and two co-founders build it. There is no account manager relaying messages, and no junior team you were not told about.
Engineering
Hassan Jamal
Co-founder and Lead Engineer
Writes the migration and application code, runs the performance work against the acceptance criteria in your scope, and is the person who answers when something breaks after launch.
- Author of all 77 engineering guides published here
- Public code at github.com/hassan-pandagen (opens in a new tab)
- Quoted in Woman's World, May 2026 (opens in a new tab)
Architecture
Imran Raza Ladhani
Co-founder and Lead Architect
Decides the platform and data model before a line is written, and owns the operations side: the internal systems that run a business day to day rather than the pages a visitor sees.
- Owns and operates Panda Patches, which we built and maintain
- Designed the internal operations platform that runs it
- Architecture and data-model decisions on every build
- Founded
- February 2026
- Mailing address
- 701 Tillery St Ste 12, Austin, TX 78702, United States
Delivery standard
What should be clear before approval
Written acceptance
Deliverables, exclusions, test pages, browser support, performance methodology, ownership, warranty, and remedies belong in the accepted written project terms.
Documented access and handover
Repository, hosting, domains, accounts, licenses, and handover timing are documented so control is not implied or left until launch.
Why clients choose us
What we will put in writing.
Not slogans. Each of these appears as a term in the accepted project terms, which is where you should hold us to them.
You own everything
Source code, design files, CMS models, documentation and production accounts are transferred to, or created under, your control. There is no proprietary layer you have to keep paying us for, and no scenario where leaving means starting over.
A measured speed target
A 90+ Lighthouse target on mobile and desktop, for representative pages named in your scope, verified across three recorded runs before handover. It is a lab acceptance test with stated conditions, not a promise about rankings, traffic or revenue, which nobody controls.
No platform rent
We do not charge a monthly licence to keep your own site running. You will still pay third parties for hosting, a CMS or email if your build uses them, and we document those costs and who owns each account before you approve anything.
Your exposure is capped at the deposit
Payment is normally 30% at onboarding and 70% at the delivery milestone, after you have reviewed the work. So you never pay the balance for something you have not accepted. Where scope protection is included in your accepted terms, we refund the fees paid under that scope if we fail to deliver what was promised, which at that point is the deposit. The terms define the trigger, verification and cure process. It is not a change-of-mind refund, and we would rather say that plainly than bury it.
Fixed price, no hourly billing
You approve a number before work starts, and that number holds for the agreed scope. Anything outside it is quoted and approved separately before it is built. A common structure is 30% at onboarding and 70% at the delivery milestone.
Support after launch
Discussions typically start at 15 business days for Starter and 30 for Growth and Scale. What it covers, when it starts, and what counts as a defect versus a new request are written down, so nobody argues about it later.
A launch you can reverse
Your current site stays live until you approve the new one. Redirects, analytics, forms, DNS, monitoring and a documented rollback path are agreed before cutover, so going live is a decision rather than a leap.
You talk to the engineers
Two co-founders scope your project and two co-founders build it. There is no account manager relaying messages, and no junior team you were not told about. If we think repairing your current site beats rebuilding it, you will hear that from the person who would have done the rebuild.
Four stages
How the work is governed
Architecture and implementation stay connected to the commercial scope. If discovery shows that the current platform is the better option, the recommendation should say so.
Discovery
Review the current platform, URL set, content model, integrations, traffic profile, business goal, timeline, and budget range.
Written scope
Document assumptions, open questions, dependencies, exclusions, acceptance criteria, and third-party costs before implementation.
Build and test
Build and test representative templates, then validate redirects, forms, analytics, accessibility, and launch responsibilities.
Cutover and handover
Cut over against a written checklist, retain a rollback path, and complete the evidence and handover defined in the accepted project terms.
Evidence policy
Claims need a date, method, and limitation.
Performance, cost, ranking, conversion, revenue, testimonial, and delivery figures should be published only with the source, measurement conditions, permission, and review date needed to interpret them. Search rankings, field performance, revenue, and AI citations remain controlled by external systems and are not guaranteed by a technical implementation.
- Visible copy and structured data must agree
- Lab results must name the tested profile
- Third-party costs must include assumptions
- Commercial remedies belong in accepted written project terms