43 karma · joined January 19, 2011
Your app looks great, what's your tech stack/any design system you use?
Since then, we’ve gotten tons of feedback and have been impressed by the wide variety of workflows people have built on Flowdash. We originally expected to see a few common usage patterns emerge from early users, but were surprised by how different everyone's use case is. Despite being different, the common thread is having a queue of tasks that need to be moved by people through a pipeline. That motivated us to continue making the platform customizable enough for people to build their unique workflows.
Another big learning (obvious in hindsight?) was how hard it gets to maintain a complex workflow without a visual editor. It's not uncommon to see workflows with 10+ stages. We’ve been hard at work taking all the feedback, and I’m excited to share our latest iteration with HN.
While the product evolved, our thesis hasn't changed. We believe operations teams are critical to many companies, yet tend to be underserved when it comes to the tools they use. The choices are either hacking things through spreadsheets, Notion, Airtable, Zapier, Slack, etc... Or investing a lot of time building and maintaining internal tools.
We created Flowdash specifically to offer the best of both worlds. You can build powerful workflows in minutes and without code, but they can be further customized through built-in blocks (i.e. widgets) and API integrations.
Here's a quick demo video where I build a basic content moderation workflow in a few minutes: https://www.youtube.com/watch?v=yAE8ePk0qa0
We also opened up sign-ups if you want to try it out. Excited to hear what you think!
Since then, we’ve gotten tons of feedback from customers and have been impressed by the kind of workflows people built on Flowdash. We’ve been hard at work taking all the feedback, and I’m both nervous and excited to share our latest iteration with HN.
Our thesis is that operations teams are critical to many companies, yet tend to be underserved when it comes to the tools they use. The choices are either hacking things through spreadsheets, notion, airtable, zapier, slack, etc... Or investing a lot of time building and maintaining internal tools.
We created Flowdash specifically to offer the best of both worlds. You can build powerful workflows in minutes and without code. But it can be further customized through built-in blocks (e.g. widgets) and API integrations.
Customers have described Flowdash in many ways: “Jira + Zapier”, “API-backed spreadsheets”, “Semi-automated workflows”, “Retool for async flows”, “human in the loop platform”, and even “Human-powered background jobs”. But since a picture is worth a thousand words, here’s a 5mn video I just recorded of me creating an approval workflow: https://app.tella.tv/story/ckhf7zbj7000009mnceo747nz
It’s the first time we open sign-ups and would love to hear your thoughts! :)
Thanks!
The recommended fix appears to mess with the `layout.css.devPixelsPerPx` configuration and even then, font is inconsistent when moving from external monitor to laptop screen.
- https://callumprentice.github.io/apps/iss_photo_explorer_fla... - https://callumprentice.github.io/apps/iss_photo_explorer_fla... - https://callumprentice.github.io/apps/iss_photo_explorer_fla...
So a mix of personal finance, dashboards, and lists.
> but is that really the real added value of your solution for a customer?
It's two-fold: 1/ On the engineering side, there's immediate value in freeing up time that can be used elsewhere. Also, because we've built a lot of the features operations teams would need as they scale (e.g. task assignment, analytics, common integrations), we expect a lot less "feature requests" to make their way back to engineering. 2/ Operators are arguably benefitting even more from Flowdash, as they're able to update how they work on their own. Many operators we've chatted with expressed frustrations from being unable to change their workflow, or having to wait 6+ months for engineering to make simple updates to their tools.
> how do you convince these type of customers to migrate?
Short answer is, it depends. If the current process works well, has no pain points, and requires no new features for the foreseeable future -- why change? However, if business is evolving (or team is growing), that's where the maintenance cost of these tools starts to grow quickly. Companies may find themselves building basic task assignment at first. Then, some sort of audit log for debugging issues. Before you know, you need notes for team collaboration. The team grows a bit more and you have to build analytics, and so on... Our goal is to partner with companies throughout their growth with the features they'll need to keep the business running efficiently.
> your solution doesn't really help the operators (=humans) to resolve the problem faster
In the demo video, it's not immediately clear how we help operators resolve their problem faster as the API simply talks back to the core application. However, actions can be setup to automate many of the more mundane tasks that operators have to do (e.g. sending email, triggering alerts, generate documents).
> so called "alarm/alert fatigue", how does your solution helps companies do more with less?
Alert fatigue is real, I'm glad you brought that up. I know it's cliché to say we're the one tool that hopes to bring all the others in a single place... but that's what we're trying to do. For operators, "Work" can originate from many places such as email, slack alerts, another person in the organisation, and so on. Keeping track of all those places makes it hard to be efficient, and also causes things to fall through the cracks. By making it easy to push data into Flowdash from various sources, we want to become the single place where operators have to work from. There's a lot of work to get to that ideal, but that's the vision :)
Using Git, and using pull requests as code reviews are two very separates things. Many people addressed the first point (e.g. Why git is totally fine), so I'll focus on the second one: code reviews with Git. Pull requests is one of many ways to do it, which I personally find difficult with bigger teams working on non open-source projects. I'd recommend looking at Phabricator as a code review tool that works really well in teams.
I also find it pretty easy to convert Objective C code (from tutorials/StackOverflow) to swift, in particular with the help of auto-completion. So in my opinion (from someone who just started, so take with a grain of salt), I would definitely suggest Swift
Along the way, you'll probably hit many roadblocks (e.g. ruby? php? html? ftp? git? heroku? aws?) but overcoming them through research, trial and error will teach you a lot about software engineering and you'll come out of the experience more educated. There's also an added benefit of building up a portfolio that shows you care more about solving problems (remember, we started from an idea) than a specific set of technologies (only a tool to execute on said idea).
When you think you're "good enough" to provide value to a company, I would start applying to job openings in parallel. Good luck! I'm actually a mechanical engineer by education, but transitioned to software after graduating using the method described above.
That being said, it is also possible to generate a native image (using ngen) to transform CIL into native code for a specific machine. But that approach is the exception more than it is the norm.
More: https://productforums.google.com/forum/#!category-topic/chat...