# Optimized 6amMart: the same script, measured and fixed

> Source: https://www.allsweb.com/6ammart-optimized
> Markdown for agents: https://www.allsweb.com/6ammart-optimized.md
> Publisher: AllsWeb (www.allsweb.com)

AllsWeb installs the latest 6amMart release — same script, same admin, same apps — on code we measured and fixed. Customer screens run 10× to 22× faster than stock, 342 defects are closed, and a suite that ships with the build proves it.

The optimized code is included in the installation price. It is not an upgrade, an add-on or a tier.

## At a glance

- **faster on customer-facing screens:** 10× – 22×
- **defects found and fixed:** 342
- **commits across five repositories:** 799
- **delivery once requirements are complete:** 1–3 days
- **Where to buy:** https://www.allsweb.com/third-party/6ammart
- **Evidence pages:** https://www.allsweb.com/6ammart-optimized

## The same 6amMart. Different underneath.

It is the same 6amMart — the current release, whatever 6amTech is shipping on the day we build your install. The same admin panel, the same vendor panel, the same customer, store and rider apps, the same data model, the same features you saw in the demo. Nothing was replaced and nothing was renamed. What changed is underneath: AllsWeb spent fourteen working sessions measuring the script, profiling it, and fixing what the measurements found — 799 commits across five repositories between 13 July and 9 August 2026, on the backend, the admin panel, the website and the three apps. Every one of those changes had to return byte-identical data before it was accepted. This is not a different product you have to choose. It is how we install 6amMart now.

### What you are buying

- **The service is unchanged** — Complete installation, setup and configuration of 6amMart on your hosting — admin panel, vendor panel, Android APK + AAB, iOS build, customer website, your branding, SMTP, Maps, Firebase push and OTP, social login, your payment gateways, your language file, and the customized source on a private GitHub repository.
- **Delivery** — 1–3 working days once your requirements are complete.
- **Free lifetime support** — For setup issues and small fixes.
- **Your own CodeCanyon license** — You buy and own your own 6amMart license from CodeCanyon; we install on top of it.

The optimized code is included in the installation price. It is not an upgrade, an add-on or a tier.

## One sentence, and one finding

The database was not slow. The application was asking it the same question hundreds of times per page.

The part most people have not seen On one customer endpoint, a single request issued 112 database queries. Eighty-six of them — 76% — were issued while converting the finished result into JSON to send it, because attribute accessors fetched lazily, once per row, at serialization time. Seven fetched the data and eleven prepared it. That is why adding indexes alone would have changed nothing: the cost was not in the queries the page ran.

That endpoint now issues 45.

86 ÷ 112 = 76.8%, printed as 76%. The source prints 77%; a source rounding up does not license this page to round up.

## Before and after, on the same server

### The method statement

| Condition | What it was |
| --- | --- |
| Before | The stock script exactly as CodeCanyon shipped it at the time of the experiment — baseline commit d92ce004, 8 July 2026 ‡ |
| After | The same script after the AllsWeb optimization and hardening program, with the vendor's next release layered on afterwards |
| Server | The same machine for both runs — 2 vCPU, 3.9 GB RAM |
| Method | Measured server-side, with the CDN bypassed |
| Scale of change | 799 commits · 342 fixes · 171 speed changes · 37 features |
| Acceptance rule | Every performance change had to return byte-identical data before it was accepted |

- **‡ What was measured.** — The before-numbers were taken against the stock script as CodeCanyon shipped it on 8 July 2026 — the release 6amTech numbered 4.0.1 — and the vendor's next release was layered onto the optimized code afterwards. That is a statement about the experiment, so the before-numbers can be reproduced against the same starting point. It is not a statement about what you receive: we install whatever release 6amTech is shipping on the day we build. Substantial further work landed on 13–15 August 2026 that the 9 August report does not cover.
- **The acceptance rule, in one line.** — "Faster was never allowed to mean different."
- **Rounded against us.** — Where a measured value is a range, the multiples here are computed the least flattering way the numbers allow — the lowest "before" divided by the highest "after". Our own report quotes midpoint multiples, which come out higher.

Nine rows, all before/after, and they are not all the same kind of measurement, so the table says which is which. Rows 1–5 are response times taken on the same server with the CDN bypassed. Rows 6–7 are counts of database questions per page, where "CDN bypassed" is not a meaningful condition. Rows 8–9 are not server measurements at all and carry a †. These are the rows a shop owner actually feels, not the biggest numbers we have.

| # | What it is | Stock 6amMart | Optimized | Multiple |
| --- | --- | --- | --- | --- |
| 1 | Featured items on the home screen | 8.19 s | 0.37 s | 22× faster |
| 2 | Product search | 1.64 – 1.96 s | 0.09 – 0.12 s | at least 13× faster |
| 3 | Storefront home page | ~1.47 s | 0.073 – 0.096 s | at least 15× faster |
| 4 | Top categories | 3.34 s | 0.27 s | 12× faster |
| 5 | App configuration on launch | 0.53 – 1.15 s | 0.045 s | at least 11× faster |
| 6 | Store earnings export — database questions per page | 8,614 | 12 | 717× fewer |
| 7 | Product catalog listing — database questions per page | 557 | 92 | ~6× fewer |
| 8 | † Styling shipped on every website page — a build-output byte count, not a server timing | 921,603 bytes | 12,386 bytes | −98.6% (74× smaller) |
| 9 | † Ten app requests in sequence — measured from a handset over mobile data, not on the server | 6,140 ms | 1,876 ms | −69% (3.2× faster) |

† Rows 8 and 9 are not server measurements. The "same server, CDN bypassed" framing covers the response times in rows 1–5 only; the styling figure is a build output and the ten-request figure was taken over mobile data.

**The arithmetic, printed** Row 6 prints 717×, not the 718× our own report writes: 8,614 ÷ 12 = 717.83, and this page does not round a figure up in its own favor. Row 9 prints 3.2× for the same reason — 6,140 ÷ 1,876 = 3.27. Row 8's byte count is 921,603 ÷ 12,386 = 74.4, printed as 74×. The 76% above is 86 ÷ 112 = 76.8%, rounded the same direction.

**Concurrent capacity, stated the only way the evidence allows** On the same 2 vCPU server, under a load ramp against the store-listing endpoint, 13× more customers can use it at once on the same server. The underlying requests-per-second pair is deliberately not printed: the source records the load ramp without stating its concurrency or its duration, and a requests-per-second figure that cannot name its endpoint, its concurrency and its duration does not go on this page. The SixPanel figure further down has all three, which is why that one is printed as a rate.

## Two rows that are not a speed story

| What it is | Stock 6amMart | Optimized |
| --- | --- | --- |
| Endpoints returning a server error on a clean install | 3 (popular stores, latest stores, payment methods) | 0 — all three now answer in 41–150 ms |
| Known dependency security advisories, counted 9 August 2026 | 111 | 0 |

## The three causes worth naming

They are what make the table believable.

- **The earnings export asked for the wrong thing 2,867 times.** — It told the database to fetch each transaction's store through the order, while the code read the store directly from the transaction — a different link. The instruction never applied, so all 2,867 rows fetched their own store separately.
- **Every vendor page drew two navigation menus.** — One hidden by the stylesheet, both counting the same order badges.
- **A page header loaded the store's entire order history.** — 466 orders for the busiest store, to fill a section of the page that had been commented out.

**And the index finding** Ten of the columns the database joins on had no index at all. After indexing, one lookup went from reading 51,074 rows to reading one.

The admin customer list was examining 16,092,496,536 rows to return 98 — 82% of all slow-query time on the server, and up to 18 minutes for a single page load.

## Performance, security, correctness

### Performance

Database questions per single request — every one verified byte-identical before the change was accepted.

| Operation | Stock | Optimized |
| --- | --- | --- |
| Product catalog listing (31 items) | 557 | 92 |
| Vendor order list (41 orders) | 212 | 12 |
| Order details formatting (40 rows) | 121 | 4 |
| Customer order history | 166 | 97 |
| Wishlist (6 items) | 140 | 37 |
| Store listing | 78 | 39 |
| App configuration | 54 | 21 |
| Category list | 43 | 16 |

The admin and vendor panels had never been measured — stock 6amMart's own automated checks only cover the customer API. 586 admin and 165 vendor pages were profiled, counted in database questions "because a count is exact and repeatable while a stopwatch on a shared server drifts".

| Screen | Stock | Optimized |
| --- | --- | --- |
| Store earnings export | 8,614 | 12 |
| Admin order search | 259 | 14 |
| Flash-sale product picker | 186 | 42 |
| Product gallery | 166 | 48 |
| Rental provider list | 159 | 9 |
| Reels store dropdown | 127 | 62 |
| Customer detail page | 106 | 34 |
| Rental vehicle list | 94 | 13 |
| Store earnings page | 89 | 13 |
| Every vendor page, before its own content | 61 | 52 |

Website
- Of the 921,603 bytes of styling on every page, 902 KB was three complete icon libraries — 21,459 icon definitions shipped so the site could display 89 icons. The build now emits only the icons actually referenced, and total styling per page is 12,386 bytes, −98.6%.
- Shared JavaScript 429 kB → 269 kB (−37%).
- The landing page was an empty shell until JavaScript loaded; it now ships 273,110 bytes rendered by the server.
- Configuration requests: one per page view per visitor → one per minute per language.
- The Maps library was being sent to 9 pages that show no map.
- Per-row date formatting: 8.45 µs → 0.39 µs (21× cheaper).
- All 50 website routes improved or held; none grew.

Mobile apps
- Every request was opening a brand-new secure connection instead of reusing one — roughly 426 ms per request on mobile data. Ten sequential requests: 6,140 ms → 1,876 ms.
- Home screen: ~30 requests per launch → 1 request covering 14 sections.
- A 1000×1000 photo was being decoded behind a 40-pixel avatar; images now decode at the size actually shown.
- 309 debug logging statements were shipping inside the released apps. Now zero.
- Rider GPS: 360 → ~30 position reports per stationary hour.
- The vendor order screen redrew everything every 10 seconds; it now redraws only when data changed.

### Security — the specific holes found in the script as sold

Nothing in this section is a preference. Each is a defect present in stock 6amMart, and each was reproduced before it was fixed.

- **Unauthenticated SQL injection reachable from every store listing.** — The store-listing code inserted the raw latitude and longitude request headers straight into the SQL distance calculation. Reachable with no login and no token. Confirmed reaching the database — an injected payload produced a database syntax error in the live log. Fixed with bound parameters; a second, unused injection point was deleted.
- **Any customer's orders readable and editable by anyone.** — More than six order endpoints accepted any order ID together with a guessed guest ID. Reproduced live: a request with no authentication at all returned another customer's items, prices and delivery address. The wallet-payment endpoint on the same path had no balance check. Fixed with an ownership scope across every affected endpoint, while keeping legitimate guest checkout working.
- **Payment gateways switched off could still settle payments.** — Turning a gateway off in the admin panel only removed it from the customer's choices — its callback URLs stayed live, and many gateway callbacks mark an order paid on nothing more than a status word in the URL. With every gateway switched off, a callback still executed successfully, so a customer could confirm their own order without paying. Fixed fail-closed; 102 probes across every gateway prefix now confirm that none executes while inactive.
- **Vendors could act on other vendors' data.** — Any vendor could edit or delete another store's products, add-ons and banners — including the admin's own home-screen banners. Replying to a review reassigned that review to the replying vendor's store. Fixed with store scoping.
- **A live demo-login backdoor — and what it did not reach.** — 6amMart ships a demo shortcut so an app-store reviewer can sign in without an SMS. It reads the phone number and code from config, with the demo values as the fallback when config is absent — and config is absent exactly once a site runs the standard production caching step, which every live install does. On the live site, one hardcoded number was being handed a working code with no SMS sent and nothing in config asking for it. The impact was bounded, and we state the bound: no account existed on that number, so the path led to a new account with phone verification bypassed — not a takeover of anyone's existing account. The fallback is what made it dangerous: an operator who had never heard of the setting still shipped the backdoor. 28 automated checks now prove it cannot exist unless deliberately enabled.
- **The whole project folder was readable over HTTPS.** — 6amMart points the web server at the application folder rather than public/, held back only by a hand-written deny-list. A deny-list protects the paths somebody thought of; fourteen were not on it, each confirmed with a real request — including a 679 KB installer database dump, a 5.9 MB archive of the public folder, and one PHP file that the server actually executed, returning a fatal-error page that disclosed the server's absolute paths. The web root was moved to public/; all fourteen now return 404, and 19 automated checks hold it there.

**Also closed**

- **Every invoice was downloadable by anyone who could count.** — Order, subscription and trip invoices were enumerable by URL.
- **Stored XSS from vendor to admin.** — Vendor-written product descriptions rendered as raw HTML in 8 admin and vendor screens, so a vendor could run scripts in the admin's browser. Sanitized, and proven safe against 25,726 live product descriptions with zero changed visible text.
- **Payment callback replay.** — Callbacks were not idempotent, so a replayed callback credited the customer twice. Fixed at hook level across all 47 gateways.
- **An open redirect on the app-redirect route.** — A phishing shape on your own domain. Fixed, then fixed again when a backslash bypass was found in review; a 17-case test now guards it.
- **Two public debug routes.** — One ran a cache-wipe command with no authentication, the other was an open image relay. Both deleted.
- **laravel.log downloadable from the internet.** — Containing the database username, failed SQL with its bindings, and full server paths.
- **One application key shipped to every install.** — The example environment file carried a real key; a fresh environment file copies it, and the key-generation step only fires on an empty value, so it was skipped — every install built that way ran on the same key, printed inside every copy of the product.

### Correctness — the money defects

| Defect in stock 6amMart | What was measured |
| --- | --- |
| Coupon minimum spend was never enforced | Admins could set it; the code never read it. Proven live: a coupon requiring a ₹999 minimum was accepted on a ₹1 order. Six live coupons had minimums set. Now enforced in all three places an order can be priced. |
| Discounts were judged by the wrong clock | The database ran on UTC and the application on India time — measured live at 5h30m apart. An 18:00–22:00 evening discount never matched during the evening and switched on at 2–3 a.m. Worse, the listing screen and checkout used different clocks, so a store could be advertised discounted and charged full price. |
| Add-on quantities were charged against the wrong add-on | Quantities were paired to add-ons by position in a list, but the customer's app sends menu order while the database returns internal-ID order. Demonstrated on the server: an order intended at ₹270 was billed ₹550. Fixed in all 8 places in the code that did this. |
| Stock was decremented on the wrong product | A campaign purchase looked the product up by campaign ID against the products table. All three live campaign IDs also existed as product IDs. |
| The checkout stock guard checked a different number than it wrote | The final check compared the product's overall stock; the decrement happened on the chosen variation's stock. Measured on live data: 56 active products where a legitimate purchase would be refused, and 1,451 where an oversell would go undetected. |
| A repeated gateway callback credited the payment twice | Also triggered by a customer refreshing the return page. Fixed at hook level across all 47 gateways. |
| Buy-now checkout priced whatever the phone sent | Rather than the server's cart. |
| A withdrawal could be approved twice and leave a wallet negative | Reproduced live: approving twice credited the withdrawn total twice and drove the pending balance to −50.00. A back-button or a double-click was enough. |
| Order IDs were assigned by hand | The code read the highest existing order ID and added one — re-implementing auto-increment badly, and colliding under concurrent checkout. |
| Two riders could accept the same order | And two customers could buy the last unit. Check-then-write races, now atomic database claims, proven with concurrent transactions. |

**Non-money correctness worth listing**
- The scheduler had never run. Five scheduled background tasks had never executed once since deployment — the system cron entry was never installed.
- The monthly payout job ran four times a month (the schedule was written as "days 28–31" rather than "last day of the month").
- Order history reported every store as unrated — 0 stars everywhere, while the real rating for one store was 4.31 across 29 reviews.
- Rider deliveries never counted toward product popularity — the increment loop used a property name that does not exist on that record, so the block silently did nothing, skewing every "top products" ranking.
- Push notifications were silently disabled — queued to a worker that might not exist; nothing delivered, no error raised.
- 34 server errors across the admin and vendor panels → zero.
- A vendor with no store row took down 9 of 12 pages of its own panel, the vendor web login, and the store app's login — one shared helper returned the first element of an empty relation, which raises instead of returning null. 43 checks, including paired assertions that a legitimate vendor still passes.
- One admin report has never worked on any installation of this software — it compiled to invalid PHP and always failed. Found by checking all 895 screen templates; it was the only faulty one.

### What ships with the optimized install that stock does not

| Capability | What it is |
| --- | --- |
| Automated verification suite | Scripts you run yourself. Each assertion was proven to fail against the old code before it was accepted — a test that passes on a broken system proves nothing. At the 9 August report the 60 scripts were 55 assertions plus 5 reporting tools, and the reporting tools assert nothing. Plus 49 unit and feature tests. |
| Schema reproducibility proof | The database can be rebuilt from the code alone — proven by building it from nothing and comparing all 184 tables, column by column and index by index, with no differences. |
| SixPreflight | A server-readiness tool: ~134 checks across hardware, PHP, application health, permissions, web server, caching, database settings, public exposure and every outside service. Open it in a browser before launch and it tells you what will break. |
| Deployment runbook | Documented install and update sequences plus the traps: which commands silently clear the config cache, which caches do not rebuild each other, what the hosting panel undoes when you save a setting. |
| iOS builds | All three apps signed and building for Apple as well as Android — the first Apple builds produced for this project. |
| Live order tracking actually on | The websocket service turned on and the two defects that kept it off fixed; certificate renewal proven. |

## Check every number yourself

The verification suite ships with your install. On your own server:

- `bash tests/Scripts/run-all.sh` — # the verification checks
- `php  tests/Scripts/api-smoke.php` — # sweeps every API endpoint

- **Each assertion was proven to fail against the old code before it was accepted.** — A test that passes on a broken system proves nothing.
- **The endpoint sweep fires 306 requests.** — It reports server errors and response times per endpoint — so "zero server errors, zero endpoints over 250 ms" is a thing you re-run, not a thing you take our word for. Read the rejected count on your own run before you read the timings; see the operating note below.
- **The suite includes the security assertions.** — Not just the speed ones: the web-root exposure sweep, the demo-OTP backdoor check, the payment-hook idempotency check, the cross-account guards, the cache-poisoning checks, and an audit of which GET routes write state.
- **The schema check rebuilds the database from the code alone.** — It diffs all 184 tables against your live one.

## What this page does not claim

A page that says "here is what we measured, here is how to check it, and here is what we have not solved" is harder to disbelieve than one that only prints its wins.

- **342 defects were found and fixed. Nobody can enumerate what remains.** — That is the honest shape of a platform this size.
- **Nothing in this program measured any other vendor's work.** — So this page makes no claim about anyone else's build. Every number here is the stock script as it shipped at the time against our optimized code, on one server.
- **Every figure on this page is rounded against us, never towards us.** — On customer-facing screens the measured improvement is 10× to 22×, which is 90 to 95% less waiting — 22× is 95.4% and we print 95. Where a measurement is a range, the multiple is the lowest "before" over the highest "after".
- **The 10-million-order figures on this page are a scale test, not live performance.** — They come from a purpose-built database loaded with 10,000,000 orders, 1,000,000 products and 200,000 customers, deliberately run against an under-provisioned 128 MB buffer pool so it is I/O-bound like a real under-resourced server. The audited production install holds 3,282 orders.
- **Six scale-test rows are still at or above one second, and we print all eleven rows below.** — Dispatch badges are 12 s; popular_products 7.1 s; the admin order list at a deep page offset 3.1 s; the item report 12.5 s for one month and 131 s for all time; the admin customer list about 1–1.5 s. The item report's all-time figure is the worst thing we measured anywhere, and the stock run it should be compared against was killed at 120 seconds, so we cannot even claim an improvement there — only that ours finishes.
- **GET requests that change settings are mitigated, not eliminated.** — The browser-driven exploit path is closed and verified; the 64 admin and vendor routes themselves still write state on a GET, and converting them to protected forms was deliberately not attempted because it is a large regression risk on a platform that is currently working across many derived projects.
- **The guard is broader than the vulnerability.** — A harmless read-only listing is also refused if it arrives as a prefetch or an image load, because separating the panel's ~860 read-only addresses from the 64 dangerous ones needs exactly the fragile list we chose not to write. There is a one-line switch to turn it off.
- **Rate limiting is safe because of where the servers sit, not because headers cannot be forged.** — The configuration trusts forwarded headers, which holds only as long as nothing can reach PHP except through the proxy chain. A box reachable directly would let a client forge the header and get a fresh bucket per request.
- **App download size barely moved.** — About 0.7 MB in total, because the unused code we removed was already being discarded by the release compiler. We make no app-size claim.
- **Three items on the reference install are open and named rather than hidden.** — The Google Maps keys are unrestricted and need locking down; an Apple Sign-In private key that stock 6amMart's own upload helper had placed in public storage needs revoking and reissuing; and three vendors still have no store row — the 500s that state used to cause are fixed, but the state itself is still reachable because both registration paths save the vendor and the store outside a single transaction. All three are in the handover document.
- **On the reference server, the hardware is now the limit, not the code.** — Load tested at 20–40 concurrent users with zero errors; at that point the 2 vCPU machine saturates.
- **All of these benchmarks are one server, one dataset.** — They are enough to say what changed on this install. They are not a general statement about every 6amMart deployment.
- **Stock 6amMart is a widely used commercial product.** — The defects above are stated as facts, which is enough.

### The scale test, printed in full — every row, including the bad ones

| Screen | Stock | Optimized | Still slow? |
| --- | --- | --- | --- |
| Admin order list, first page | 27.4 s | 13.6 ms |  |
| Order-count badges on every vendor page | 136 ms | 20 ms |  |
| Item report, this_week | killed at 120 s | 542 ms |  |
| get_stores | 9.8 s | 901 ms |  |
| Order-count badges on every admin page | 8.5 s | 830 ms |  |
| Admin customer list, first page | 20.7 s | ~1.0 – 1.5 s | ≥ 1 s |
| Admin order list, deep page offset | 100 s | 3.1 s | ≥ 1 s |
| popular_products | 12.8 s | 7.1 s | ≥ 1 s |
| Dispatch badges | 29.8 s | 12 s | ≥ 1 s |
| Item report, this_month | killed at 120 s | 12.5 s | ≥ 1 s |
| Item report, all_time | killed at 120 s | 131 s (365-day floor) | ≥ 1 s — the worst row we have |

**Will this matter to me?** At a realistic 100,000 orders — thirty times the audited install's current volume — and with the order-badge windows switched off, all nine screens profiled at that volume measure at or under 250 ms, and six of the nine at or under 50 ms: vendor badges 3.4 ms, get_latest_products 10 ms, customer list 31 ms, item report 46 ms, popular products 47 ms, store listing 50 ms, dispatch badges 146 ms, admin order list 155 ms, admin sidebar badges 179 ms. The badge window (ORDER_BADGE_WINDOW_DAYS=60) is a shipped setting, and whether it is on changes these numbers, so we state the condition the measurement was taken under.

## Questions buyers actually ask

### What am I actually buying?

The same thing AllsWeb has always sold: complete installation, setup and configuration of 6amMart on your hosting — admin panel, vendor panel, Android APK and AAB, iOS build, customer website, your branding, SMTP, Google Maps, Firebase push and OTP, social login, your payment gateways, your language file, and the source on a private GitHub repository. Delivered in 1–3 working days once your requirements are complete, with free lifetime support for setup issues and small fixes. The optimized code is how that install is built now.

### Do I get the same 6amMart?

Yes — the latest 6amMart release, whatever 6amTech is shipping when we build your install. Same admin panel, same vendor panel, same customer, store and rider apps, same data model, same features. Every performance change was gated on returning byte-identical data before it was accepted, so your screens show what they showed before, faster.

### Does the optimized code cost extra?

No. There is no separate product, no separate license and no premium tier. The installation price in the catalog is the price, and the optimized code is included in it. You still buy and own your own 6amMart license from CodeCanyon.

### How much faster is it, really?

On the live server, with the CDN bypassed: featured items 8.19 s → 0.37 s (22×), top categories 3.34 s → 0.27 s (12×), product search 1.64–1.96 s → 0.09–0.12 s (at least 13×), the storefront home page ~1.47 s → 0.073–0.096 s (at least 15×). Row multiples are computed the least flattering way the measurements allow. The typical figure across customer-facing screens is 10× to 22× faster — 90 to 95% less waiting.

### Where do those numbers come from, and on what hardware?

Before is the stock script exactly as CodeCanyon shipped it at the time of the experiment — the method note above footnotes which build that was and why the footnote is there. After is the same script after the program, with the vendor's next release layered on. Both were measured on the same 2 vCPU / 3.9 GB server, server-side, with the CDN bypassed — not on a bigger machine, and not with a CDN doing the work. Two rows in the comparison table are not server timings and are marked as such: a build-output byte count, and a handset measurement over mobile data.

### Can I verify any of this myself, or do I have to trust the page?

You can verify all of it. The verification suite ships with your install: bash tests/Scripts/run-all.sh runs the checks and php tests/Scripts/api-smoke.php sweeps 306 API requests and prints the response times. Each assertion was proven to fail against the old code before it was accepted, so a pass means something. One caveat we would rather tell you than have you discover: a valid sweep has about 66–68 requests rejected by the platform's own rate limiter, and a run with hundreds rejected should be discarded.

### Will 6amTech's own updates still work on it?

Mechanically, yes — it has been done. The vendor's next release was layered onto the optimized code, and further work landed after the 9 August report: cache hardening, a rebuilt expense listing, and an application-key defect that affected every install built from the vendor's example configuration. The honest detail is that our fixes sit in the same files 6amTech ships, so a vendor release is a merge we perform for you, not a file-by-file overwrite you run yourself.

### What happens when 6amTech ships the next 6amMart release?

If you are buying now, you get it — we install whatever is current on the day we build. For an install we delivered earlier, the same thing happens as for any customer on any of our catalog scripts: moving to a newer release is the standard update service at 50% of the installation price, because the configuration from your first setup is reused. Applying it to the optimized code is the merge described in the previous answer, and it is our work, not yours.

### What security problems were actually in the stock script?

Reproduced, then fixed: unauthenticated SQL injection reachable from every store listing; any customer's orders and delivery address readable without signing in; payment gateways that were switched off in admin but whose callbacks still settled payments; vendors able to edit other vendors' products and banners; a live demo-login backdoor (bounded — it led to a new account with phone verification bypassed, not to taking over an existing one); fourteen project paths readable over HTTPS, including a 679 KB installer database dump; every invoice enumerable by URL; and an API with no rate limit at all — 40 wrong-password attempts in a row were all accepted with no throttling and nothing logged.

### Will it still be fast when my shop grows?

Up to roughly 100,000 orders, yes: nine screens profiled at that volume, with the order-badge windows off, all measure at or under 250 ms and six of the nine at or under 50 ms. That is thirty times the audited install's current volume. Beyond that, read the scale test in Honest limits above — it is not all wins. At 10,000,000 orders against an under-provisioned database, the admin order list goes from 27.4 s to 13.6 ms, but dispatch badges are still 12 s, popular products 7.1 s and the all-time item report 131 s. Those are scale-test numbers on a purpose-built database, not your live server.

### Do you claim there are no defects left?

No. 342 defects were found and fixed. Nobody can enumerate what remains in a platform this size. What we can show you is what was measured, how to re-measure it, and which items are still open — the Honest limits section on this page lists them, including the scale-test rows that are still slow and the routes we mitigated rather than rewrote.

### What are you still not happy with?

Several things, and we would rather you read them here. In the 10-million-order scale test, six rows are still at or above one second — the worst is the all-time item report at 131 seconds, and the stock run it should be compared against was killed at 120 seconds, so we cannot claim an improvement there at all; dispatch badges are 12 seconds. Sixty-four admin and vendor routes still change state on a plain GET — the browser exploit path is closed and verified, but the routes themselves have not been converted. And on the reference install the Google Maps keys are unrestricted, an Apple Sign-In key needs revoking and reissuing, and three vendors still have no store row.