I am currently testing the app. Maybe, for more engagement, start processing cards faster just after installation. It feels weird to have to wait 30 minutes, just show me at least a card. Like the fact that I am installing DayFlow would be a positive experience.

Compliments for the Wizard - that one works perfect at least with Gemini. One little detail: You have a Github Star button in it, that really was at a non-logical place and made me think.

Really cool!

As already seen in the comments there are lots of desires to add more data compared to just screen input.

Could be things like:

- Apple HealthKit / watch - custom apps - Phone logs

Also you stated, and true, that there is much focus needed on improving your core feature.

It might be interesting to allow some kind of API / plugin area. So that people can expand on your core feature and add the desired parts. Might in the future expand to some kind of AppStore like feature with plugins.

That would keep your work focused and allows others to make it complete in their vision, and for others.

Generally an archive link under it is posted which is kinda fine. Not all news is available on public websites which would be a negative if it is not there actually maybe?

One of the most challenging things I currently find is that it’s complicated to keep the ai tools focused and at the same time with enough understanding of the full project.

In small parts they excel really quickly but in bigger apps they seem to write for example helpers everywhere which are already available. Think date formatting.

So that would worry me a bit, it would literally explode the code size of the own project.

There are solutions off course but in general that’s for now a thing I would be careful of. Later that will be better I’m sure.

Seems to work great!

Little note: when you switch from redaction to view with the redaction tool (red lines) active it stays active in the view mode. Impossible to scroll because it still redacts.

Refresh fixes it.

Good catch, I’ll fix that. On mobile, it’s intentional that scrolling is disabled while in redaction mode so you can make precise selections, but if you switch back to the view tab it should definitely exit redaction mode. Thanks for spotting it!

Not sure if it matches your vision but I just took a look at the react example:

https://www.embedpdf.com/docs/react/getting-started

I would suggest that you start with a more simple example. like:

<EmbedPDF url={https://snippet.embedpdf.com/ebook.pdf}/>

It would just take one additional component in your NPM package which contains all the more "internal" stuff. Just put the advanced example you have now in one component.

The example with the engine etcetera looks more like an advanced example.

It gets a developer to a quick result in their own app. If they want to go further they can nothing changes there.

A sidenote: That same though might be something with your NPM import - just one would be a better dev experience to start while I understand why you offer them separately for more advanced.

This is really valuable feedback, thank you! I agree, having a simple, ready-to-use `<EmbedPDF>` component that includes all the plugins by default would make it much easier to get started. I’ll definitely add that alongside the more advanced example.

Not really if an URL link is added to the post in the comment response.

Also it is possible to embed a sub resource (or part of it).

Think a blog post.

/blogPost/:blogPostId

You can embed a blog object with the url and title so you can show the blogpost on a page with the name of the blog in one go.

If you need more details on the blog you can request /blogs/:blogId

Generally only /companies/:companyId/buildings

And then you get a list of all buildings for this company.

Every building has a url like: /buildings/:buildingId

So you constantly get back to the root.

Only exception is generally a tenant id which goes upfront for all requests for security/scoping purposes.

This seems like a really good model. It keeps things flat and easy to extend.

Do you also cache all request in your store in for example the situation:

Shopify delivered. You cannot deliver to shipstation.

What happens when then the dunk restarts?

Did you try running some ai over it to see if it is capable of being useful?

Legacy code is a statement but in the end it only matters if it works and is maintainable.

It might surprise you.

I got mixed results. A good portion of the code was written by former employees. There is little documentation.

I think there are quite some software engineers willing to take a look at the code to test/validate/fix interesting research proposals.

When the right amount of info is shared a lot of cooperation is possible and challenging for both I suppose.

The added value for both is learning the other skill. Gaining a broader knowledge to engage further in career and life.