HN user

Chetane

43 karma

email: <username> <at> gmail.com

Posts11
Comments43
View on HN

Congrats, looks interesting. For higher value items and furnitures, I currently have a spreadsheet with price, and screenshots of product specs. Very useful when time comes to sell them :)

Your app looks great, what's your tech stack/any design system you use?

Hey HN, I’m Omar, one of the creators of Flowdash. We first shared Flowdash on HN last year when we were just getting started (https://news.ycombinator.com/item?id=22476985).

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!

Hey HN, I’m one of the creators of Flowdash. We first shared Flowdash on HN earlier this year when we were just getting started (https://news.ycombinator.com/item?id=22476985).

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!

One major (and unexpected) issue I ran into with Thunderbird is font size. On my monitor, it's way too small to be usable.

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.

Hey! Omar here, co-founder of Flowdash. Thanks for playing devil's advocate, and for so many great questions -- I'll try to take a stab at it, and curious to hear your perspective on it as well.

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 :)

Was hoping the source code would also be good ol' hand crafted html, with <table> elements used for layout and so on...

Your CV is too long. Maybe not in terms of content, but the layout makes it 6 pages which is very unusual - Most interviewers look at a lot of resume, and don't have time to "extract & filter" out what matters most from the 6 pages: that's your task. I would suggest reducing it to 1-2 pages, only keeping what is most pertinent (caveat: things like 1500 subscribers from your Youtube channel is pertinent, as it shows passion about what you do, being pro-active in it, and giving back to community). That being said, sounds like you've got a lot of experience, and definitely sounds like you're better than you think :) Just make it easier to notice via you CV.

Git pretty 12 years ago

my company decided to move just to use pull requests as a poor man's code review tool

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.

Thanks all for the recommendations. I also found the CapitalOne 360 cafe to be pretty nice on the second floor (bonus: TV for world cup games :)). Interest is a bit slow, but the area is nice. I'll check out the other recommendations. I'm also down to meet up, I'll be here until Wednesday (traveling from SF, where I worked at a Startup there)

I've just started looking at swift since it was launched, and making really good progress so far. Having coded in Ruby, C#, C++, and C, I really enjoy and "get" swift as it's leveraging the strength from all these languages.

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

My advice to you would be to improve (or acquire) your software engineering skills through practice, by doing real life projects. What I mean by that is pick an idea/project that excites you (e.g. An interactive website for non-philosophy majors to get a high level overview of philosophy) and do it (I know, "just do it" by itself it not so helpful).

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.

C# by default doesn't generate native code. C# generate CIL (Common Intermediate Language), which only gets turned into native code at runtime by the JIT (Just in time compiler).

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.