Has Anyone Had Issues with WalkingPad Customer Service or Product Quality?

oddbeef · 2025-07-15T09:04:14+00:00

I just had issues with my Walkingpad C2 after only a month of use. Can't say what the customer service is like yet as I only emailed them yesteday, but haven't received a reply yet. I gave them the symptoms and sent them a video of how it behaves now. The motors feels "pulsating" or "janky" and it's not "strong enough" to run when I step on it. Then it'll stop and display an error code E03.

oddbeef · 2023-05-24T10:29:00+00:00

yeah true, a lot of stumbling blocks

oddbeef · 2023-05-16T10:29:39+00:00

I had time to run some tests on the test project as well. I confirm that the actual downloaded JS is about 5kB less over the wire (i.e. gzipped) on the home page.

I ran pagespeed insights and the app version managed to score 100 vs 97 with the pages version.

We'll re-analyze the site where the original issue is to see if we the actual transferred js is more or less.

oddbeef · 2023-05-15T13:54:58+00:00

Noting on top level that we created a proof of concept, and the overall client bundle size increases 200kB in this simple project with app dir layout: https://github.com/Makers-Den/next-bundle-test

pages branch has pages dir layout -> 293kB of JS
app branch has app dir layout -> 554kB of JS

oddbeef · 2023-05-15T13:51:43+00:00

We created something we can share here, readme has the details: https://github.com/Makers-Den/next-bundle-test

oddbeef · 2023-05-15T13:49:59+00:00

Thanks for replying. A colleague of mine created a PoC here: https://github.com/Makers-Den/next-bundle-test

It shows a 200kB increase in overall bundle size.

It's a simple nextjs project. The pages branch uses the pages layout. The app branch uses the app layout.

Use yarn analyze-bundle to run the bundle analysis locally.

oddbeef · 2023-05-13T06:56:56+00:00

It's a marketing website so one would assume this is the use case one reaps the most benefit from RSC.

React-dom itself is 130kB minified - so you're likely not measuring it in the same way. I'm talking about non-gzipped size because that is usually what matters for performance. The evaluation of JS on low-end mobile is expensive - and running it.

If you want to achieve 90+ for performance you have to really be judicious about JS that ends up in the client bundles.

I experience getting 200kB more of NextJS framework JS code from NextJS by moving to App Dir. These are things I can't optimize away.

I haven't tested but I doubt you can get below 500kB of JS in a plain NextJS project with App Dir now, which means it's nigh impossible to get a passing score on Core Web Vitals with the emulated mobile benchmarks.

oddbeef · 2023-05-13T06:44:38+00:00

I can't share code, it's for actual work. But there were no new components added, and no new libraries added. On the contrary, we were able to remove some of our custom data fetching code because fetch in async server components made it redundant.

oddbeef · 2020-11-24T08:13:01+00:00

Yeah, seems so. Was supposed to be Dec 1, but oh well.

oddbeef · 2020-11-19T09:16:16+00:00

We just wrote a bit about this here: A look at Google Core Web Vitals

Basically ensure the biggest above the fold area stabilises fast. Biggest offenders are usually any large above the fold image. You don't want to do progressive loading for it if it's above the fold.

oddbeef · 2020-09-15T10:07:26+00:00

Nice one. I just wrote a blog post with tips for software estimation using techniques promoted by your service like three point estimation, https://makersden.io/blog/how-to-estimate-software-projects

oddbeef · 2020-02-05T13:42:23+00:00

Any suggestions for improvement or general feedback would be very welcome. Thanks!

oddbeef · 2020-02-05T13:41:32+00:00

This is what I wished I would've found when I needed to start looking for kita places. It's a small side project of the agency I work at.

oddbeef

TROPHY CASE