You're right that getting developers to switch to visual programming will be tough. But we believe that:
1. In the right use case (standalone API/workflow, multiple LLM calls, concurrency etc.) working visually is going to be 10x better than code
2. There's a growing segment of non-developer-but-technical people: Self-taught builders, Product Managers, IT/Automation specialists. We think these people are currently stuck with existing tools that are very limiting. And once they're able to deploy real products with visual programming it will be a gamechanger for them.
3. Collaboration - Even if developers prefer textual code when on their own, when they're working with non-developers (product teams, clients etc) there's a big benefit for being able to share and present how things work.
> In the right use case (standalone API/workflow, multiple LLM calls, concurrency etc.) working visually is going to be 10x better than code
I completely agree but I think that's a very hard sell. People who write code are often years deep in their preferred workflows and asking them to reconsider how they build things is a very big ask.
> Even if developers prefer textual code when on their own, when they're working with non-developers (product teams, clients etc) there's a big benefit for being able to share and present how things work.
The problem here is that developers lead implementation. The ideal implementation for a stakeholder is rarely the implementation that is delivered, because developers are taking requirements and translating them into the things they want to build. That's why so many products end up bad: developers have too much power by virtue of code being seen as some sort of magic spell that only a true genius can master. Can you imagine a non-technical person successfully dictating that the solution must be built with visual programming?
Low code / no code is powerful because it turns the relationship between product owner and developer on its head, it puts the product owner back in the driving seat (instead of a passenger begging the developer to go in the desired direction and accepting they'll probably end up somewhere... nearby, hopefully). Hiring the wrong developer(s) can be very bad for a company because of how much a developers choice's influence the product and business.
The proliferation of low code / no code in business often comes from outside engineering, many developers, regrettably, love to write code. Often you'll find that non-technical departments of companies have secretly started using things like Make and Zapier and n8n without telling the engineering department because they feel like they finally have the opportunity to make technology work for them.
Developers that exist in service of product are already using platforms like Make and Zapier and n8n because they understand how much value there is in programming without writing code, but for them visual programming probably isn't that much of a differentiator because they already have a vision in their head of how programming works.
Anyway, your product is great, I am sure you'll succeed regardless of the approach you take :)
Agree that these tools are enormously useful for non-programmers to automate things. I think the biggest area where all visual programming languages is in scalability, flexibility, and speed compared to a skilled (text) programmer. There is absolutely space for these tools, but I think that the wide majority of people who spend enough time programming will prefer text.
The tradeoff between visual and text programming feels like a classic learning curve vs. skill ceiling tradeoff.
Devs may take time to adopt visual programming, but SME will more readily try this to improve execution. Visual programming will be the way SME and LLM build consensus on execution.
Pricing is indeed something we're still trying to figure out.
Currently we see differentiation as a combination of simplicity and elegance/visual quality.
Meaning platforms like Flicker are too cluttered and outdated in terms of how galleries look.
But in this too we still have a lot to learn and figure out.
For simply sharing specific photos - GPhotos' native share feature is great.
Our product is for people who are looking for a more advanced publishing option. Something like a website or portfolio, but super quick and easy to create.
This is simply much faster and easier than any other way.
Wordpress and other blog sites require quite a lot of effort and technical knowledge. We aim to democratize photo sharing and let anyone do it quickly and effortlessly.
Super interesting. Thanks for the detailed thoughts and link.
The thinking behind the vertical masonry grid is that by always having semi-visible pictures in view it draws the eyes down to keep scrolling.
If that makes sense.
Will definitely check out the links and consider further.
Map and text blocks - These are currently not supported, but we're still considering different use cases and will add features to match the ones we focus on soon.
Videos - These are currently not supported but might be added soon. They pose some storage and pricing issues but we'll try to solve that. Again depending on the use case we end up pursuing
Longevity - This is a legitimate concern. Obviously we're hoping that this product keeps growing and plan to maintain it. Regardless - The north star of this product is to be fast and easy to set up. So we hope that the time investment won't be that big anyhow.
Pricing and Storage - We've just launched so the pricing plans will definitely change over time. We'll take that into account.
Syncing albums - Seamlessly syncing albums to online galleries was our dream. Unfortunately Google's API doesn't support that (for obvious security and privacy concerns).
We'd love for your mom to give our product a try and will be happy to give her a generous period of free usage of the premium plan for some of her feedback.
If you're interested, please reach out at hey@myphotos.site.
You're right about trust being important.
We're working hard to show that we're real people with good intentions.
I actually didn't consider that using AI to generate some blogposts (that aren't the main content of the site) would have negative impact on how people perceive the product.
So thanks, we appreciate the feedback and will take it into account moving forward.
I think it depends on the target audience. For casual photographers many might not care about AI but poor curation makes it look cheap. For artists, if they see any hint of even minimal AI usage or hints that you may approve of gen AI it would be a total dealbreaker. For the subset of tech minded people that approve of AI, they probably already know how to host a site -> but maybe they are still a viable audience if this saves them a lot of {time|money|maintenance}.
> I actually didn't consider that using AI to generate some blogposts (that aren't the main content of the site) would have negative impact on how people perceive the product.
As a cofounder you already know your product. I don’t, and one quick and easy way to discover is crawling your site (testing your product comes second as I need a bit of confidence before sharing my google credentials). Bad copyrighting (ai gen or not) depict one interest of having more customer while not much interest in sharing useful information on the subject. I don’t know about your motives so I can only trust you "are real people with good intention" and wish you good luck, but as an anonymous visitor I surely would have passed my way.
If the guide posts aren’t mean for humans but the robots, maybe hide the link in a SEO friendly way? 10px off screen or z-indexed bellow another block for exemple.
Also a header disclaimer would be very appreciated: "Content for SEO, back home"
The problem for me is not the SEO, but the vast AI blather, which is virtually content-free. You need a complete rewrite by an experienced human. After reading and reading, all I found was subjective comments about how great all the features are, without any information about the features themselves. What is your relation to Google? Can photos only come into your site from Google?
You're right that getting developers to switch to visual programming will be tough. But we believe that: 1. In the right use case (standalone API/workflow, multiple LLM calls, concurrency etc.) working visually is going to be 10x better than code 2. There's a growing segment of non-developer-but-technical people: Self-taught builders, Product Managers, IT/Automation specialists. We think these people are currently stuck with existing tools that are very limiting. And once they're able to deploy real products with visual programming it will be a gamechanger for them. 3. Collaboration - Even if developers prefer textual code when on their own, when they're working with non-developers (product teams, clients etc) there's a big benefit for being able to share and present how things work.