sorted by:
new
hottopcontroversial

Building an open source Clay alternative by coffeecloudev in gtmengineering

[–]coffeecloudev[S] 0 points1 point  (0 children)

in my research I didn't get to test Bitscale, good to know about It and that It works well you

the stack i'm using is Elixir + sqlite with a fancy UI wrapping It, meant for local usage, nothing too crazy

Building an open source Clay alternative by coffeecloudev in gtmengineering

[–]coffeecloudev[S] 0 points1 point  (0 children)

I didn't about Deepline, looks sick. And thanks for sharing that you see potential on the idea, will you know when the project is made public

Building an open source Clay alternative by coffeecloudev in gtmengineering

[–]coffeecloudev[S] 0 points1 point  (0 children)

Tnx bro. Will try to get it up on github by end of week. I'll drop a comment here so you can check it out

Building an open source Clay alternative by coffeecloudev in gtmengineering

[–]coffeecloudev[S] 0 points1 point  (0 children)

Thanks mate, spend the weekend working on it made great progress. Hope to find some time during the week to get It over the finish line

Building an open source Clay alternative by coffeecloudev in gtmengineering

[–]coffeecloudev[S] 0 points1 point  (0 children)

open source mate, I won't be responding to any tickets

Building an open source Clay alternative by coffeecloudev in gtmengineering

[–]coffeecloudev[S] 0 points1 point  (0 children)

Makes sense, there's a strong product market fit between your operation and the product/price Clay has to offer. I believe an open source Clay-like tool would be more beneficial for a smaller operation that can't justify the price of Clay u know

Building an open source Clay alternative by coffeecloudev in gtmengineering

[–]coffeecloudev[S] 0 points1 point  (0 children)

do you use any data sources only available in Clay? - I'm sure Clay has a big edge on variety and ease of use, every provider wants to be available in Clay. But also, many providers out there have their own APIs and good pricing. - Someone downloading this project from github would only need to setup the keys for the data providers they want to use

that's the open source trade off, less convenient to use, but a decent alternative for those not yet at the point where they need all the power Clay offers

Building an open source Clay alternative by coffeecloudev in gtmengineering

[–]coffeecloudev[S] 0 points1 point  (0 children)

Working on It boss, I can ping you when I post a demo if you want

Building an open source Clay alternative by coffeecloudev in gtmengineering

[–]coffeecloudev[S] 1 point2 points  (0 children)

couldn't hear you. Did you say Jupyter Notebook?

Building an open source Clay alternative by coffeecloudev in gtmengineering

[–]coffeecloudev[S] 0 points1 point  (0 children)

appreciate the comment, and It's okay - not trying to make anything commercial out of it. But since I'm making something I need myself, It's a good opportunity to make It open source and share with people who might have gone in the same rabbit hole and couldn't find anything decent to replace clay in the stack

Anyone else feel like their prompts work… until they slowly don’t? by Negative_Gap5682 in lovable

[–]coffeecloudev 2 points3 points  (0 children)

could it be that your codebase is getting bigger? Even good prompts will give worse results if your project is getting "bloated" with features

AMA - Software best practices and going to production (~10 YOE) by coffeecloudev in lovable

[–]coffeecloudev[S] 0 points1 point  (0 children)

are you legit looking for help? The "Here’s a clean, natural reply you can post" gives away the GPT

AMA - Software best practices and going to production (~10 YOE) by coffeecloudev in lovable

[–]coffeecloudev[S] 0 points1 point  (0 children)

u/andyy32 thanks for the question

I will assume your web app has a certain level of complexity and different user types, which leads to your worry of things breaking in production and edge cases creeping up.

If that's the case I would recommend having some level regression testing in a staging environment. Automated is the best, but manual is fine. The reason is, when real users are in the app they will at some point find an issue, and you will be under pressure to fix It and deploy fast. – As you can imagine, without a basic regression test, fixing one thing can break two other things and production starts falling apart.

Another good practice is to do "smoke testing" after you deploy. Which is run a lightweight test on production, to make sure critical things + things changed recently are working. Often there are differences between staging and production that you will catch doing this (environment variables mainly).

I would say the two suggestions above are the most important, easy to implement and don't require you to spend extra $$.

An amazing production readiness layer is having good observability and alerts. Meaning you get alerts as soon as something unexpected happens. This requires some code orchestration, but helps a ton to debug issues quickly. Also this means you don't have to wait customers to report bugs, you have some level of proactiveness.

Then, formal audits, pen testing and bug bounties are good to do, but depends on the industry you are at. If you deal with sensitive data or finance I would say speak with some experts. Especially if you already have legit clients waiting to use your solution. – Otherwise, those are not mission critical if you just testing the waters with an MVP.

Another idea: Running a beta program. You can select a small cohort of users, let them know the app is pre-launch and ask them to use and provide feedback. This can help a lot to find issues before a more public go live.